Having spent a few posts on .NET specific tools, I'll get back to more process and architecture oriented topics for a bit now...

As a believer in Agile and XP for delivering software (where appropriate), I subscribe to the "simplest thing that can possibly work" ethos - not overengineering a solution based upon the assumption that as yet unknown requirements will change the defined implementation.  An application of YAGNI, if you will.  Whilst numerous people in the office have taken this mantra on, I've spotted a lurking anti-pattern that's reared its head a couple of times:

"The simplest thing that could possibly get me out of work"

One of the great things about Agile/XP is that it delivers some control back to the developer, removing the need for business analysts that are basically translator-patterns from business -> technology.  This is also one of the approach's problems (which I will discuss in another Blog entry soon); If developers cling to a statement such as "the simplest thing that could possibly work", it means that they are using none of their intelligence, experience, and insight to make decisions.  Like most maxims, "The simplest thing..." is a principle to use that cuts to the heart of the majority of cases.  It is also a rod for your own back if applied blindly rather than judging the implications of all solutions.  In my opinion, a developer is a "professional" who shouldn't mechanically apply rules to derive solutions - a modicum of intelligence is required at each juncture, not a parrot-like ability to repeat a phrase.

I've seen this anti-pattern manifest itself most recently where 2 solid man days were wasted on a task that would've taken 10 minutes if there'd been an understanding of what "simple" implied, and the more elegant solution hadn't been discounted for not involving the simplest steps.

This leads, for me, to two rules:

• Whilst in the vast majority of cases, the simplest approach is the best one, there are numerous other cases where something that is only marginally more complicated will clearly give many times the potential going forwards.
• The "simplest thing" and the "quickest thing" are quite often very different.  "Simple" could mean going through 100 files by hand, manually searching for similar text and overtyping it where needed.  "Quick" could mean hitting Ctrl-R in a decent editor and typing in a simple regular expression.  I know which of the two options I'd choose.  And, unfortunately, I know people that would choose the other option, protecting themselves with the "shield of simple".  The "sum of simple" should actually be: simplicity-of-each-step x number-of-steps.

The problem with simplicity is that it exhibits no intelligence.