Have you ever been in a situation where you were forced to act knowing that the margin for error was zero? I think that most of us have, perhaps just avoiding an animal on the road without swerving into oncoming traffic while driving. In a crisis, the most appropriate response usually comes not from thinking, but simply allowing reflexes to take over.
If you are a software engineer, you will enter what I call the panic room whenever your reflexes say run like hell and doing so is not a possibility. You have three months to rescue something that has been languishing for three years and you know that there is zero room for mistakes. Every line of code you commit must be your friend next month, going back to the drawing board is not going to be an option. It is a recording with one take, every single thing you ship gets carved into stone.
What exactly is the panic room? It is a place where smart people go to observe everything and play with possibilities to try to determine what course of action is going to be the correct course to take. It is the process of removing yourself from the problem in order to more effectively solve it, while everyone else sees you wasting time and not committing anything. It is not your happy place, it is your safe place and you need to be prepared to go there and seal the door. You might wait in the panic room for a while, so you better make sure it is stocked. Until you stop seeing sales guys jumping in front of the camera demanding to know when they can show what you have yet to fully write to clients, don’t open that door. Until e-mail bullets asking for ‘layman overviews’ of what you are doing stop coming in, don’t open that door. In other words, don’t come out of that place (and risk completely hosing your project under pressure by making a single large mistake) until the annoyances have given up and left.
Now what exactly do you bring with you?
Take your code. You need to roll simulations, you need to look at everything you inherited and what you have cooking and ask yourself if you can be comfortable using it as is. There is no time to refactor, there is no time to fix code smells. Can you just push forward and not succumb to going backwards? Until that answer is yes, don’t open the panic room door.
Take sane methodology, such as Knuth’s law, Brooks’s law and even Bradford’s law. A copy of Hanlon’s razor helps to tolerate the incessant pounding at your door. Occasionally, consult William Of Ockham, just to be sure you aren’t becoming part of the problem you are trying to solve. Take silence with you, let your family know that you are pulling off something extremely difficult and what the rewards of doing so will mean to them. You are going to the panic room to sort out a problem while protecting yourself from influences that can only amplify the problem. This means, cut yourself off from everything but the problem at hand for lengthy periods during the day, and leave yourself some time to unwind later.
Since we, programmers and engineers don’t carry a shell on our back, we have to be able to do a mental retreat. The day will come when you do too, so I highly recommend constructing and envisioning your own panic room. Draw it out, sketch it out. Give yourself all of the room and creature comforts that you want, then put it away. When the time comes, you’ll be very very happy that you have a retreat
When you emerge, you won’t need much time to put something definite into code. Until you scream EUREKA!!! , do not open that door.