Deadlines are not that bad

Reading time ~1 minute

In my current project we had a hard deadline: we had to go to public beta on August and finish the transition of all users to the new system by the end of August. When we knew those dates our first reaction was this one:


Depending on the environment you work the reaction to these news are usually some combination of a lot of pressure from management, working a lot of hours, drop the quality of your code, hysteria, etc.

To be honest, we had some of that, but the main reaction was the right one: scope management. If you have a deadline, and assuming that hiring new people won’t ease your life, your last chance to success is to manage the scope of your project. Decide what is really really really important, what the users can’t live without and implement that. And nothing more. We conducted some workshops to do this work (the whole team, not only the product owner and business analyst) and the result was a reasonable product backlog to develop.

Apart from that, the team increased the commitment with the quality of his code. We increased the time doing pair programming, we did some mob programming for some difficult issues, we did lots of code reviews.

I’m not going to lie you and say that we were pleased to have such a hard deadline, but I think some of the consequences of having it have been really positive for the final product. Is far better to have an incomplete product that your users can use and give feedback than a super fancy product that nobody use.

Using different configuration per stage

In the [previous article](./deploy-serverless-app/) we saw how to create a basic deployment pipeline for a serverless application. In thi...… Continue reading

Deploying a serverless application

Published on April 19, 2018

Dynamic secrets with Vault

Published on December 16, 2017