A couple years ago I have been involved with a company that found itself in a rather unenviable position. It spent a little over six months building an ambitious and complex product which by the time I joined was generally considered to be “almost ready to be released” (some parts of it, anyway). Unfortunately, it also had a long list of bugs and - as we soon found out - serious maintainability issues. Furthermore, two of the original developers left the company soon before I came on board (and with them, most of the domain knowledge) and four new came in.

We also had a deadline.

We were asked to deliver an MVP that was to be released to tens of thousands of users world-wide by the end of next month.

We spent the following days and weeks working around the clock trying to figure out how to fix the legacy codebase not allowing ourselves to question the design/architectural decisions made by the developers before us. You could hear it literally everywhere: "We really cannot afford to touch this component because we won't be able to hit the deadline if we do".

After six weeks of this self-induced paralysis we did not deliver virtually anything. The system was still as broken and as unmaintainable as before and because new requirements were being added - now that we finally had the manpower - it was actually less complete than the old one.

Then it turned out the real business deadline (presentation to investors) was actually due in another six weeks. Uh oh.

Deadlines, estimations and legacy codebases

Invariably, the first question a developer hears before they start working is: “How long will it take you to implement this?”

Now, we all know software estimation is hard. And it is, it really is. That said, in certain cases - if you have done your planning properly, if you know the chosen technology and if the requirements are well understood - you will probably be able to come up with an estimate and most likely your answer will not be too detached from reality.

In other cases however - e.g. when you’re dealing with unknown legacy codebases and/or scary DBs full of data noone understands anymore - the only honest answer is “I have no idea and it will take me quite a long time to figure it out.” As a rule of thumb, when any legacy codebase is involved, developer is worse off than when starting from scratch.

So, how long will it take you, then? Well that depends. In agile methodologies (think Scrum) estimation usually works like so:

  1. Get the requirements and understand them.
  2. Break them into small pieces to manage their complexity.
  3. Figure our (together) how each piece might affect the system and estimate how long they will take to implement.

If you don’t understand the requirements or if there’s an external source of unknowns (legacy code), estimation loses all of it's meaning and worse: it becomes misleading. At this point any tight deadline becomes toxic. It will force you to make bad choices (“keep the buggy code to hit the dealine” as opposed to “sit down and understand or (potentially) re-think the architecture”). You will be worse off than without one.

When deadlines actually work

Of course, there is a valuable use case for deadlines. It is when they are used for what they really should be used for. Deadlines are essentially a prioritization tool.

When you have a well-understood plan and you’re able to move towards your goal in iterations, deadlines serve as a reality check. They help you tell when you need to renegotiate the scope of the project and reshuffle priorities well ahead before it’s too late. In other words - they help you prioritize what's to be delivered.

To paraphrase Spiderman's uncle, having the power to set deadlines comes with great responsibility. Nine women will not make a baby in one month and a deadline will not make a bad project turn good. First, address the issues and make sure you're on the right course and thing are moving forwards. Then set a deadline.

Conclusion

Imposing deadlines on an underperforming developer team does not work. In fact, not only that it does not work, it will in many cases force developers to produce low quality code and make bad decisions that will harm your project. If you're falling behind your schedule, deadlines will not help you; in fact, they will kick you in the teeth.

First get your stuff together, then think about timeframes.

Agree or disagree? I'm @tomas_brambora.