Here's how to recognize a Faerie Dust request:

1. We have identified a problem. It can be with almost anything: scalability, reliability, auditability, any Quality Measure .

2. We're pursuing a specific technology. Typically, something that has the lowest impact on our architecture.

3. We can't address anything other than this …

"There has been a lot of skepticism about the usefulness--and necessity--of the Ribbon, and I have to admit that I was among the doubters. Why change something that works? Because, according to Microsoft, the current interface has become bloated with too many menus."

Ugh. It's bloated, so we'll add features …

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".