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 …

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 …