The team received the following link in an email from our team leader along with an enthusiastic endorsement of the article's central tenets:
http://www.joelonsoftware.com/items/2009/09/23.html

The article, entitled `The Duct Tape Programmer` basically promotes an idea which is summed-up briefly by the following quote:
`` When you are done, you might have a messy go-cart, but it’ll sure as hell fly.``

For go-cart, read `Application`. The author argues that `Design Patterns` is a dirty phrase; that multi-threading is dangerous, and that multiple inheritance sucks.

Here's another quote from the article: [Quote]
Here’s what Zawinski says about Netscape: “It was decisions like not using C++ and not using threads that made us ship the product on time.”
Peter asked Zawinski, “Overengineering seems to be a pet peeve of yours.”

“Yeah,” he says, “At the end of the day, ship the fvcking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

My hero. [End Quote]

The author (and his hero) also dislike unit testing (?!) The motivation for this approach, as the article says, is that sometimes you need to go from zero to shipping in 6 weeks. Then you don't have time for pretty code.

Of course, I agree. If something needs to be done urgently, then urgently is how it should be written; but I'd sure as hell hate to have to come back to maintain that hastily-written cr@p in a few months (which is almost guaranteed to happen) because it'll be spaghetti code. I mean let's face it - where's Netscape now???

At any rate, my response to the team leader was that tools are just that, and nothing else. Overengineering an application is bad. That's because it's overengineered! Over-anything is bad, that's what it means in the English language: overeating, overdrinking, overexercising... but no one, surely, is arguing against eating, drinking or exercising???

Long-time members will probably remember my rant in this very same forum when I had just resigned from a horrible job with an 90+ project solution driven almost entirely by abstract classes, interfaces and delegates - empty implementations galore! It was a freakin' nightmare, and my gut-instinct was that the project had gotten away from even its own designer. This is a shining example of overengineering. On the other hand, to go for a blanket ban against unit testing, multi-threading, design patterns and other detailed (but not necessarily complex) engineering tools, this seems akin to robust and obdurate ignoramusness (to coin a phrase).

I am especially disagreeable with the team leader's stance, especially in light of the fact that his T-SQL code is littered with magic numbers - Select blah From BlahTable Where blahColumn In(232, 433, 33, 22, 55, 553) - what the fcuk those numbers are meant to be is anybody's guess, but it's alright because the app has to go out in 6 weeks. Need something more in the app? No need to revisit/rethink the design - just stick a new column into a table. So okay, we've got dozens of columns in hundreds of tables in dozens and dozens of severs (here's yet another email from the Head of Development asking if anybody knows what YadaYada table in BlahBlah server is doing!)
but at least the app is going out in six weeks (and coming back in seven).

So, ladies and gentlemen, your comments please?