Have you already be confronted with this scenario:
After 24 hours you have to deliver a version or an update to a client and the version is not ready yet, or at the last time, a serious problem occurs and you have to work under pressure to deliver the product.
How do you manage this situation? do you adopt the Jack Bauer attitude where you do many things evil and you are convinced that If you want results, you have to get your hands dirty. It’s just part of the job, something that has to be done (and the job must be done). It is evil that is pragmatically necessary, unavoidable.
Concretely to achieve your tasks under pressure you can:
- Unable to accept feedback, criticism, or suggestions.
- Be aggressive towards your colleagues.
- Modify the structure of the database few hours before the delivery.
- Do many code changes in the machine where you package without even commit the code.
- After many changes, you package without doing any tests because you are very confident that you did the right changes.
This attitude will just make the situation worse than before. We are not in a fiction and you are not Jack Bauer 🙂
To avoid having this kind of situation the obvious solution is to have a mature delivery process which can limit the damage.
Many processes exist now to improve the software delivery
Here’s a definition of the continuous delivery process from Wikipedia:
Continuous delivery treats the commonplace notion of a deployment pipeline as a lean Poka-Yoke: a set of validations through which a piece of software must pass on its way to release. Code is compiled if necessary and then packaged by a build server every time a change is committed to a source control repository, then tested by a number of different techniques (possibly including manual testing) before it can be marked as releasable. Developers used to a long cycle time may need to change their mindset when working in a CD environment. It is important to understand that any code commit may be released to customers at any point. Patterns such as feature toggles can be very useful for committing code early which is not yet ready for use by end users. Using NoSQL can eliminate the step of data migrations and schema changes, often manual steps or exceptions to a continuous delivery workflow. Other useful techniques for developing code in isolation such as code branching are not obsolete in a CD world, but must be adapted to fit the principles of CD - for example, running multiple long-lived code branches can prove impractical, as a releasable artifact must be built early in the CD process from a single code branch if it is to pass through all phases of the pipeline.
The theory is awesome but in practice, you can have many cases which require you to work under pressure. And what you need also a good attitude to face any unforeseen.
Here are some bits of advice useful when you work under pressure:
- Stay calm, remain fearless: See the situation as a challenge, not a crisis.
- Keep it simple: Find order in the chaos and maintain clarity of thought. Work on the things that really count. Don’t get emotional or defensive.
- Address the Most Urgent Need First: When unexpected things happen, Prioritize as you go, and that way you’ll get through the decision-making process. It’s crucial to discern between a real emergency and something that can wait.
- Listen: You have to be flexible and pay attention to what people are saying so a scene doesn’t go astray. Often the group mind is more intelligent than anyone given perspective. Yes, even yours.
- Break down each major task: It helps immensely to break down each major task into smaller manageable tasks. Once you start working on the smaller tasks, your state of anxiety will automatically diminish, as you will be working actively to get it done.
It’s also awesome to have people with this kind of attitude to face the urgent problems but in practice, it’s not obvious. So what to do? is there any magic solution to face this kind of situation?
Maybe a company has to continuously improve the delivery process, and on the other side continuously improve the developer’s attitude by coaching them. A process is nothing without well-formed workers. And the well-formed workers can’t do awesome things without a good process.