Saturday, August 02, 2008

Seven square number of Problem-Solving-Items (PSI)

Seven square number of Problem-Solving-Items (PSI)

What are problem solving items?

As a first-level approximation, they are requirements + “architecture” requirements.
However, they also include technical design items, source control items, testing items, support items. They include all problems. For details why I put all of them together, please read my previous blogs.

Of course, we all know that our corporate world does not like the word “problems”, we find all different words for it, “issues”, “challenges”, etc. I do not like those other words, and I like the word “problem” – I like all the honesty, history, weight, and power that go with it. However, I do understand and appreciate the needs from the corporate world; so, I add a positive word with it, and add an “unit” word, hence the phrase, “problem-solving-items”.

What is the “7-square”?

Psychology shows that the short memory of human’s brain can only handle 7 items. The optimal is half of it, around 3. That is the reason that when we speak or write, we use 1, 2, 3, or 4, not that often we use more than 4. If we really need to, we re-organize them, make it two levels, 1, 2, 3, under each item, we have a, b, c.

You may believe it is trivial. I do not believe so. I believe the universe is “consistent” or even “anthropic” – see http://en.wikipedia.org/wiki/Anthropic_principle . As a result, I believe those 1, 2, 3 things are “consistent” with those “thesis”, “antithesis”, and “synthesis” in Hegel’s philosophy.

I apologize to drag you into this physics-philosophy-psychology indulgence, that is my weakness; but I am also very practical and pragmatic, so, let’s be back to the real business.

IT (Information Technology) is about handling large amount of information. Its complexity comes from the large amount of seeming unrelated items. As a result, we have to maximize the capacity of human minds. In short, we have to use 7, not 3; further, we have to use two levels, instead of just one. And use two levels all at once – we have to treat the two levels as if there were one, i.e. we have to treat 49 items all at once, and not make the two levels too restrictive.

In short, next time you think about IT, just think about “49 PSIs”!

------------------
There are no categorical differences between the "problem solving" in sciences and that in engineering disciplines.

Further, the best minds, or, at least best documented best minds, due to the very nature of basic sciences, are not in engineering, but in basic sciences.

As a result, in addition to Lean literatures, I will resume my love for reading philosophy and history of sciences.

http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing06.pdf

http://philsci-archive.pitt.edu/archive/00004037/01/The_reductionist_blind_spot-08-05-01-2300.pdf

Friday, August 01, 2008

Problem Solving Logic-Centric Lean Process (PSLCLP)

I believe I am in a creativity storm.

I believe I found out the problem of all “software processes” and “IT project management”. It is the “inductionism”, we need a “deductionism” paradigm shift just as Karl Popper did in philosophy of science.

I believe the key is indeed “requirement gathering” – the starting point of the waterfall, it is wrong, everything is wrong.

We need to replace it with “problem”. The whole thing should be “problem solving”.

The name of the process should be Problem Solving Logic-Centric Lean Process (PSLCLP), I know, it is long. The key is to remember “problem solving”.

testing, testable, Lean, science, and Occam's razor

The effort to apply Lean to software makes me think, very hard.

It is about the core waterfall, by that I mean: analysis, design, implementation, teat, and deployment.

I want to eradicate them. To me, those concepts are simply a pretentious way to say that we are working toward a new system.

TDD is good in the sense that it has already started to break this core waterfall: it says that let’s put aside “analysis, design, coding, and testing”, let’s treat everything as testing – that certainly is disruptive and revolutionary!

Of course, the problem is that, this revolution concept is mixed and therefore buried or at least eclipsed by other concepts like “stories” -- but that is another story, of course.

Then, the concept in philosophy of science hits me: “testable".

Usually we believe software engineering is engineering, and therefore we use metaphors from other engineering. However, perhaps we should think about software more in the terms of science – philosophy of science, logic of science, and logic-psychology of problem solving?

After all, modern engineering is based on science; and recent science is more and more “big science”, i.e., engineering based science – science of man-made.

After you cut the fat of the waterfall, we can see some many new things, or, new old things!

More about why Lean and science: heard about Occam's razor (http://en.wikipedia.org/wiki/Occam ). Science is the leanest enterprise by human being!

some blogs I got when I googled ockham razor and six sigma:

http://usercentricea.blogspot.com/2008/05/occams-razor-and-enterprise.html