While "Browser as OS" is what appears to be happening. The browser is the front-end for many applications. Even in the Ajax case, however, the browser is only one piece of the application, and the browser isn't relevant on the server side.

The important point that is missed in the …

Here's another symptom of a Request for Faerie Dust™:

A proposal that includes (1) analysis, (2) proof-of-concept, and (3) a plan for a solution.

Sounds sensible, doesn't it? Study it, prove that you can solve it, and write the complete plan to solve it.

Sounded sensible to me, until I …

Without mentioning Armour's The Laws of Software Process: A New Model for the Production and Management of Software (which includes the Five Orders of Ignorance, quoted by Paul Freedman in "Uncovering Ignorance in Software Development "), Purdy has hit the nail on the head regarding gestation of architectures.

Is Gestation overhead …

The customer -- usually someone from IT -- has met with the users, and determined what their problem is and what is required to solve it. This is the standard procedure, but it rarely works out well. Here are some scenarios and some coping strategies. After some hand-wringing about scope and budget …

First, let's pick the conclusion out of the middle: "However, the computation for the first and last business day of the month is trivial. So, just codify this."

Since we still lack any usable context, we're struggling with the definition of basic terms. Is this the calendar month, or the …

Here's the example:

"I need to calculate first 'business day' of the month. Last 'business day', too."

Note that the problem which this solves is unstated. Why does anyone need to "calculate" this?

Here's a single tidbit of technical context, not useful really, but all I know: it's a polyglot …

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 …