Don’t Panic

It’s no wonder the Hitchhiker’s Guide to the Galaxy was such a bestseller with the bold words Don’t Panic sprawled on the cover. Successful software development shares this same sentiment. Don’t, under any form of duress, panic. Even at the threat of having your livelihood cut short.

I suppose it was TDD, Agile, XP, and all the usual suspects that, over time, instilled within me the confidence to not panic under any given situation. Well, to be honest, most situations. And within software there is no shortage of situations to induce panic right from the business through to the development layers. Polytricks *sic* included.

Unrealistic deadlines, scope and resource availability to get the job done; team dynamics and psychology; technical hurdles; environmental and infrastructure glitches; all these going wry at the wrong time, and if it does go wrong it will be at the wrong time, can introduce panic into any team via one or more individuals. It’s exactly at this time, that the team/product/project/company/individual is defined. What you do at this critical point is what ultimately defines your commitment to methodolgy, principle, philosophy, vision and holds you accountable for all you’ve said and done in moments where panic was not lurking.

Yes, it’s easy to say all the good stuff when there’s no pressure to deliver. Stick to your guns when there is pressure to deliver… IF by Rudyard Kipling comes to mind… and you’ll be a programmer, my son!

The most important reason not to panic for me is: whatever it is that makes you successful, you must never forsake. Especially not for panic. So if it’s UML, TDD, waterfall planning, Agile practices, pair-programming, guess-timating; and you’ve identified exactly what it is that has made you successful; don’t drop those practices because of panic. You then start playing a game that you’re not used to with rules you can’t play by and immediately you’re disadvantaged and you will be beaten simply because Panic has more experience than you playing the panic game.

Yet it surprises me how time and time again we revert and tred underfoot those very things which work for us, all because suddenly, in panic mode, we can do things better by doing them a different way:

don’t write tests
skip QA
release untested
don’t run tests
don’t estimate how long it will take to fix the bug
cut a corner anywhere, anyhow, whatever you do, just do it quicker.

And somehow, all these mandates replace and more surprisingly, convince a development team that they can operate better without any of their usual safety nets because Panic will make sure that their work is of superior quality than the work produced with no Panic.

Yet, sadly we know this is not true. Yet we fall into the trap of not walking the truth.

Panic fixes, not tested, not documented, not QA’ed are superior? If that was so, why don’t we write all our code under panic 🙂 which, actually, is a reality for some teams.

And i suppose that is where some of the problems lie. Some developers are too used to writing panic code that they have little experience of code quality outside Panic; and therefore cannot compare their current quality to anything else. So as long as there’s Panic, there will be good code. Does burnout mean anything to you?

I prefer not to Panic. Keep calm. Relax. Whatever the reason for panic, there’s always a plausible explanation. Besides, the code you’ve written and the bug you’ve just deployed 🙂 is just doing what it was programmed to do. All that’s required is a change. No Panic. Panic, and your change introduces other untold changes…

Until the next panic then… 🙂