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.