When we're Holding the Hammer, everything's a nail. There are a number of supporting arguments for this. I won't beat down the All Those Features™ decision-making pattern again. That, and some part of Tomorrow's Dollars Don't Exist™ decision-making pattern are in "Is it Over-Solving or Exploiting Technology? "

From Improving-NAO : "I …

One of the best ways to avoid problem solving is to treat the problem as fluff. Often, our users begin the conversation with this assumption, and we play along. Other times, we make this choice because we're just too lazy (or negligent) to make an effort.

Here's how it plays …

Here's a snip from a comment:

"... over-solving the problem is writing a bunch of custom code (the file readers and writers) when there is already a perfectly good mechanism available for all of the persistence, reliability, repeatability and scalability issues. To me, if my application has already been designed to …

R. Lucente shared an email with me that included Cary Millsap's Volume Theorem.

Theorem:

No human wants to see more than 10 rows. Ever.

Which caused me to wonder why anyone would ever use an RDBMS as a slow, complex, high-overhead message queue. I've seen it done several times, and …

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 …