There’s a dangerous tendancy in the programming industry to spend one’s whole time fire fighting.

Because we’re largely deadline driven, there is always pressure to get things done yesterday, which inevitably leads to corners being cut in order to ship stuff on time.

Some of this is pragmatism, and entirely justified in the context of needing to turn a profit in order that everyone gets paid - but I believe that a big danger lies in the fact that fire fighting is habit forming. It’s a mentality which is very easy to slide into, and once you’re in it, it is hard to escape.

If I had to sum up a programmer’s fire fighting state of mind in words, it would be “I haven’t got time to do this properly”. Most of the time this is utter bollocks. A more accurate translation would be “I can’t be arsed to do this properly”.

Unfortunately most technology projects are run by non technical people who aren’t in any way qualified to tell which of these two statements applies in any given situation. Worse than that, they actively encourage the “haven’t got the time” mentality, which plays right into the hands of the “can’t be arsed” mentality - “look boss, it should have taken two weeks, but I got it done in a day (it doesn’t work for a few edge cases which I haven’t spotted yet, it breaks encapsulation, doesn’t follow any of our standards, and is totally unmaintainable, but did I mention that I got it done in a day!).

Larry Wall is fond of saying that a truly great computer programmer is lazy, impatient and full of hubris. When he says "lazy", he means in it a good way - as in "I don't want to do the same damn thing again and again, so I'll do it properly now, in order to avoid future wasted effort".

Unfortunately, the vast majority of programmers aren’t great - they’re just lazy - and the kind of laziness involved in the quick bodge is seductive. They live in a world where most people (especially their bosses) don’t know what they do or how they do it. What begins as a “I know I shouldn’t, but I’ll bend the rules just this once” soon becomes second nature, to the extent that the part where the programmer works out whether they “have time” to do it properly gets missed out entirely, and it’s just assumed that there isn’t time. Worse still, many programmers don’t even for sure what “properly” actually means. They may know it in an abstract, “this is what the lectures said” way, but they haven’t learnt the truth of it through bitter experience. The quick bodge method seems to work fine (for a while), and by the time they realise that it doesn’t actually work at all, it may be too late for them to get out of their bad habits.

This isn’t some sort of calculated wickedness on the part of programmers. There’s nothing suprising in it - it is simply human nature - which is the very reason why it should be actively fought against by managers who have the foresight to encourage quality and excellence (not to be confused with self-indulgent noodling).

Most corporate environments strive hard to keep their employees cocooned away from any “negative” temptations, such as the temptation to read email, surf the internet, or (heaven forbid) think about something apparently unrelated to work. This is usually futile and counter-productive and tends to produce sterile environments where all creativity is suppressed. So it’s doubly ironic that programming studios often seem hell-bent on actively encouraging their technical staff to give in to the temptation to produce sub-standard work in the name of spurious efficiency.

What they don’t realise is that quality and pride in your work isn’t something that can be turned on and off at the flick of a switch. The more corners one is asked to cut to meet deadlines, the more the pride in one’s work is eroded, with serious long term effects as a result.

The good programmers tend to react to this state of affairs by getting frustrated and grouchy. They either start doubting themselves, or they get pissed off and leave (often discovering in the process that the grass is no greener elsewhere). Or they retreat into their own world, ignoring both reasonable and unreasonable requests for a pragmatic approach, and become completely un-manageable.

The efficient but unimaginitive programmers thrive, because they are good at doing stuff quickly, and clever enough to layer hack upon hack and keep everything running against all the odds. There’s always a brick wall, and eventually the project hits it, but by this time the efficient programmers have made enough of a name for themselves as people who “get things done” that they are seen as the heroes. They can make a compelling case for throwing everything away and starting again, but they don’t really have the imagination or motivation to design the new version properly, thus beginning a new cycle of bodging.

The vast majority of the other programmers just go with the flow - happily pottering along and never stretching themselves or achieving their potential. They may have it in them to become great, but they probably won’t be arsed. Life is easy, they can get enough done to keep the bosses happy, and they don’t ever really have to make the mental effort to actually think hard about anything in order to do it right. It is so much easier to bodge than it is to come up with an elegant design.

Sadly these people are destined to never discover how much more satisfying it is to do things well, to come up with a really clean design, then implement it. They will never experience the pleasure of working with something that is well thought out and knowing that you are reaping the benefits of earlier planning and discipline.

More sadly still, the studios that employ these people are ultimately destined to fail. It may take years, but they will slide slowly into decline as the products that they make become ever slower, more bloated, uglier and less reliable - whilst the managers scratch their heads and wonder where it all went wrong.