The following weirdness often happens when we encounter complex business problems.

1. The users hate something and want new software. They justify a project to spend $100K replacing something that appears broken.
2. The Business Analyst notes a control issue that is really a conflict between software functionality and business rewards.
3. The …

In Rat-holes of Lost Time [Rat-Holes of Lost Time ], I thought out loud about software development and how the resulting software product may or may not be of any value. In SEI terminology [view_qm ], this is Need Satisfaction. Sometimes I call it Solving The Problem ™.

I tried to distinguish two …

Much of software development is best described as "problem-solving". Much of the rest, BTW, is knowledge capture.

When we look at the time spent on problem solving we can see four potential outcomes.

1. Time is spent producing a viable solution to the actual problem.
2. Time is spent producing a non-solution …

In it, Bruce Silver recollects process reengineering gurus who warned "Don't pave the cowpaths!". Presumably because the cow path was a random walk all over the pasture land, and wasn't the most efficient course.

However, anyone who was watched cows at work will tell you that the cow path is …

In principle, stating a problem is a trivial exercise: someone can't do something. It can be made wonderfully complex, however. The root cause of the complexity could be a fundamental unwillingness to state the problem without including technology hints like "database" or "hierarchy" or "project management" or "change control".

"Polymorphism is nice as well, although I can't grok (yet) why this is necessarily not part of non-OO things. I'm not clear that it goes with the strong binding of state and method in a class."

Polymorphism isn't necessarily part of OO. Python actually has polymorphic functions outside of class …

See Holub's column "Requirements Gathering" [Requirements Gathering ] for the goods on what is actually useful and what isn't so useful in this activity we call "Requirements Gathering".

I have to applaud the notion that "focus on the minutiae" misses the whole point. A clear problem statement is perhaps more important …

Here's a possible match-up between the Seven Deadly Sins and Seven Species of Complexity.

• lust for someone we cannot have - "When I Grow Up"
• gluttony or over-indulgence - "How Hard Can It Be?"
• avarice (covetousness, greed) for things we do not need - "Quality vs. Quantity of Ideas"
• sloth (laziness, idleness) wasting …

See RLucente.bloki.com: The Culture of Programming - Why Programmers Make Things So Complicated .

RL identifies 4 reasons.

1. It could be that its actually complicated
2. It could be that have not found the real problem
3. It could be that I have to patch because I can't redesign and rebuild the …