Saturday, October 18, 2008

Karl Popper and Software Engineering

Karl Popper and Software Engineering

I believe now -- 2008, in software engineering, a pure “practitioner” point of view is hitting a dead end. We need an “academic” or conceptual revolution. The revolution is to throw out the inductionism in software engineering. Karl Popper did it in Philosophy of Science. We need to expand that to software engineering.

In my previous blog, I proposed the following theory:

“Analysis/Design/Coding/Testing” corresponds to “understanding problems and anomalies/theory/solving issues using the theory/ experiment-test the theory”. Now, I am going to make it even simpler: “Analysis/Design/Coding/Testing” corresponds to “Problems/Theory/Solving Problems using the theory/Testing”.

You may say, it is just a word-game. I say it is a huge, revolutionary change. Now, "analysis" is to understand problems, not “gathering” those so-called “requirements” anymore! In meetings with users, when we ask “what is the problem” and “how do we solve the problem”, it is always more effective than asking “what are the requirements”! In fact, we all know that “requirement gathering” is the source of all problems in software development. Now, we know why – OK, pun is intended here!

I googled about it (Karl Popper and Software Engineering). Surprise, Surprise, I am not the only one!


http://blogs.msdn.com/imtesty/archive/2007/01/15/the-science-of-software-testing.aspx A deep thinker in MS!

The following is a short quote (please go to the above URL for a complete read, it is fun!):

Testing as a science
Computer software is similar to a scientific hypothesis; both are inherently fallible. The basic framework of the software debugging process is analogous to the trial and error practice that advances scientific hypotheses. Computer software is simply technical conjecture. Test engineers attempt to refute the assumption of flawless software through rigorous tests mostly designed to prove that defects exist (falsification).

The falsification process sharply contrasts with data-driven approaches such as induction and deduction, which attempt to justify validity based on the repetition of facts. Justificatory approaches mostly attempt to support claims through confirmation. Confirmation primarily endeavors to validate the error-free uncertainty by using specific data that demonstrates proper functionality. This approach clearly only proves that software functions correctly under certain conditions; it does not prove that the software is error free.

1 Comments:

Anonymous Anonymous said...

1. Popper is like classical philosophers, instead of authors in the more recent "philosophy of science", when he talksa about "science", he talks about human thinking. As a result, we are not really "expanding" from science to enginnering, we are simply re-focusing.

2. The Sciences of the Artificial by Herbert A. Simon can help us for the re-focusing. Further, the concept of "satisficing" directly breaks the myth that collecting information would lead to optimal decision, which is equivalent of inductionism.

3. theory-experiment corresponds to design-usecase also, more specifically, experiments and usecases. Now, I can see why experiments are so important for scicence. Similar concept is "operational" -- just like usecases, they are not just "examples" -- they are usecases! -- I will return to this later, but I just feel that the symmetry is powerful and deep.

survic

11/23/2008 01:52:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home