The religious zealotry of coding best practice

©bowie15 via 123RF

1. The hack-attack

The fast food merchants of code production, these guys look to get it out ASAP. Do the least possible work to get the sign-off from the customer, to get a product installed that does what it's meant to do... for the most part at least.

I actually respect these guys - you can laugh at the quality of their work, but like a fast food outlet technically gets the job done (fills the stomach), these coders are incredibly efficient. In terms of bang-for-buck, they are often remarkably cost effective.

It's fairly easy to understand the problems with this approach though. Some projects just go wrong. The code is at a level of spaghetti-ness that would impress a native Italian mafia-run dockside restaurant. Typically what happens in these firms is that a fast-build project is also a fast-fix project, so instead of accepting that the code essentially needs some level of re-write, the quickest dirtiest fix is implemented, which often only exasperates the problem.

2. The blind bind

A hooded, humming, metronomic posse of ideological devotees, this crowd have their favourite masters of code, to whom they devote their twitter and blog-reading attentions. They are the quickest to dive into the latest fads, but often they do so with religious fervour. And when the chief priest is head of the IT firm, the commitment reaches epic levels of zealotry.

There is no denying: if and when these projects finally see the light of day, and that's an important if and a slow when, they're beautiful. Hand-crafted modules are practically autographed, although to be fair, with such a movement of adherence, they're more likely to be autographed by the lead developer than showing any strain of individualism.

However, when I say "slow", what I really mean is dead. I've worked on these projects before, and I couldn't point you to a Url, because they died a stagnant death in the dead sea of introspection. In hindsight, you know that the only way to have completed the projects would have been to cut ideological corners, and there's a great wisdom lurking in that shadow. While the deal-getter promises that their customer will save money through their purist development technique, I don't buy it, and neither should the customer.

3. The murky middle

I preach to you the virtues of both: the great compromise. Get it out fast, adhere to as many principles as you can, but don't feel guilty about leaving your code littered with to-do's for future attention.

After all, isn't this the basic tenant behind agile development? Waterfall methodology says we're going to get it 100% right, so let's plan to do it that way, while agile faces the fact that demands change, budgets get altered, and customers remain forever detached from the limits of technological reality. Life can be messy, and you need to deal with the disappointments by managing your risks: get to the issue quickly, but at least cover your back to avoid the worst-case-scenarios.

The sequel: which corners to cut?

In the next few blog posts, we'll look at some of the most common forms of over-engineering.

See the next installment of Coding Zealotry here.