Deadlines!!  Panic mode!!  You’ve been there. Go on. Admit it! Some of you are probably there right now, though how you have time to read a blog post I’m not sure :-)

We know how it happens.  You started a project and provided some initial estimate which, like all estimates, was wrong.  Even so, someone in the business promised delivery of the project to their customers based on those estimates.  You realise those estimates are wrong pretty early on, but don’t want to look like you don’t know what you’re doing so you hope that you’ll catch the time up later.  You don’t tell anyone that you think you’ve screwed the pooch and stuffed up.  It’s only late in the development process when all hope is lost of ever catching up that it really becomes visible to others and a sense of panic ensues as everyone on the team starts to rush to get things done.

As this rush starts the panic grows and grips people and they forget all about those good, disciplined developer practices that you’re meant to be following and start doing things the quickest, ugliest, dirtiest way possible.  It doesn’t matter how much of a kludge or nasty hack it is, as long as it works and you finish quick you’ll be happy.  That impending sense of doom you’re feeling drives you to make all the shortcuts in the world that you promised yourself you would never do again.  You’re aiming for that short term goal of meeting a date with something, anything, which kind of works and you don’t care how many kittens have to die to get there.

So here’s the rub.  Because you delivered and maybe even satisfied the customer under these circumstances it becomes acceptable to do the same thing again the next time there is a hint of a deadline looming. All too soon it becomes commonplace to ignore good practices completely and just do whatever happens to work.

Your management doesn’t see how much sticky tape and string are needed to hold things together so to them this short-cut behaviour simply teaches them that when they pressure you, you can deliver something in a shorter time frame than you originally thought possible.  Good for them.  Less time means lower costs means more profit, right?  Armed with this knowledge management then kicks off the next project with all the ammunition they need to pressure you to deliver in an even shorter timeframe than ever before.  What’s worse, is because you as a developer don’t push back on estimates you then respond to these deadlines by making even more shortcuts than ever before.  Ugly, ugly, ugly!  And we wonder why we look at our code some times and get embarrassed. We’re a victim of our own “success”!

The other problem panic mode brings is that overtime is almost always involved. Because the hours worked by you and the team are generally well above and beyond the standard 40 hour week it looks like you complete a lot more work and thus achieve what seems like higher productivity. More ammunition for management!

And yet, your short term burst of speed, no matter how good it looks, is really quite bad.  Because you’re tired and worn out from your panic mode overtime work, all the work you do after that will be far less effective plus you’ll also be dealing with all that stuff you threw against the wall to get things done.  Extra bugs, terrible design, copy and paste development and technical debt up the wazoo!  Because management isn’t really aware of these problems or the impact of them, they start to get upset that your productivity has fallen away.  “What’s wrong with you lazy developers?!” they ask.

So, as tempting as it is, when a project is late is not the time to panic.  Panic mode rush jobs should be avoided as much as possible because of the downstream ramifications.  Obviously take into consideration the larger business implications – if not delivering means the company goes out of business and you have no job, well that’s extenuating circumstances, but if it’s just to meet an arbitrary date…? Hmmm.

The real secret, and the thing to aim for, is to manage expectations earlier and avoid panic mode altogether.  As soon as your initial estimates look messed up, admit your mistakes, talk with your customers and have those difficult conversations early, whilst there is still time to adjust plans.  Hoping you’ll catch time up later is a sure fire way to get yourself in a deep dark hole – so stop lying to yourself about catching up.  You know that the only way to catch time up is to cut corners, and you know what happens when you do that...