The Problem with Software

A friend asked, “how to start a scalable project without having to recode initial stuff when we need to put more stuff in?” I would have laughed in his face except that he asked me through email, so I could only type “ha ha ha!” which I feel dilutes the effect somewhat.

But he really has hit the nail on the head. The reason I laughed is because what he wants to do sounds so simple, yet impossible for any non-trivial software project which has at least one human being as the end user. All those methodologies and best practices out there - e.g., DRY, YAGNI, high cohesion and low coupling - have as their objective software that needs minimal recoding when requirements change.

Software development projects will cease to fall behind schedule only when the following cease to hold true:

• Human beings can hold in their heads only seven items at one time, plus or minus one or two items
• The brain is designed to organize things into broad patterns rather than to analyze absolutely everything in minute detail
• People are unable to articulate exactly what they want, but they’ll know it when they see it

The basic problem is that a software system is something abstract, voluminous and exact; yet our minds can only focus on only one thing at a time. We can’t think of everything, in detail, all at once. So that’s why users will always change their requirements - there’ll always be something they didn’t think of, halfway down the road. And that’s why software will always need to be redesigned when requirements change - it never occurred to the programmers to accommodate the new requirements in the inital design.

So to not have to recode initial stuff when we need to put more stuff in, we either need to change the way computers are being programmed (via symbols), or we need to change our brains.

3 October 2007 | Uncategorized | Comments