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.

Problem Solving Areas (PSAs), Problem Solving Lean Process (PSLP), Analysis/Design/Coding/Testing and General Problem Solving

Problem Solving Areas (PSAs), Problem Solving Lean Process (PSLP), Analysis/Design/Coding/Testing and General Problem Solving

Ya, you may say that all this blog is about names; but good names indicate the maturity of a theory.

1. I changed the 8 core "techniques" into 8 core "Problem Solving Areas (PSAs). See the 8 PSAs at the bottom of the blog.

2. In this blog, I changed the process name into “problem solving lean process”: it is a lean process, with problem solving in its focus.

3. I retreat from my noble fighting with “Analysis/Design/Coding/Testing”; now, I believe it is a paraphrase or a parallel mechanism of the “problem solving process”: thinking about problems, a theory, solve issues in the theory, and experiments for the theory. By doing this, I have “saved” the analysis/design/coding/testing, and, more importantly, saved myself from craziness! As a result of this realization, on the one hand, I am now a big fan of the micros-waterfall, because it is the same micro-mechanism of any problem solving processes. On the other hand, I do believe the micro-waterfall is flexible, any step of this micro-waterfall reflects the whole – for example, in analysis, there is testing already.


---------------------------8 PSAs

1. "OR mapping" (including "UOW", Unit of Work, equiv. to Siebel's BO)
2. ("O") "entity": rules in entities, rules engine(******), scripting in entities
3. ("U") "Web2 UI": ("ActiveX" and "Ajax")
4. "Data Binding" ("OU mapping")


5. "transaction" (and non-transaction, with "facsades" and "workflows") (business service and workflows, tasks. Also here: "unit testing" ******)

6. "networking (at application level, as "connected applications")"
--i. async and sync EAI (background) "messaging" for integration and need "user push notification" (activities or an area on every screen)
--ii. batch EIM
--iii. offline web client
--iv. reporting server
7. "logging (that is runtime-configurable)"
8. "security"("authorization" and "authentication")