This is the part that helped me understand this: "It was kind of like a miracle drug," [Ruth Samuelson] said. "It's going to do all this stuff and I just didn't think it was possible."

It appears to me, just reading this account, that there wasn't a clearly articulated problem …

Nisley says "Imagine a programming contractor proposing that increasing the average interrupt latency by 10 μs would reduce the module size by 5 percent and improve the error rate by 3 percent. When was the last time you saw precise numeric relations between various aspects of a programming project, before …

I recently reviewed some end user-authored use cases, and they -- of course -- reflect the way people actually work. The computer system was largely incidental to what they did.

Each use case listed half a dozen actors, had a dozen or more steps, and involved many off-line interactions among the actors …

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 …

The "correct" answer is to fully normalize the design and get away from a mixed bag of columns and nulls. The MESS is bad from every perspective, except query performance. A semi-normalized design that separates the STATE CHANGES from the ESSENTIAL DEFINITION is an optimal design in many respects.

Here …