Slow down to speed up

What is a deadline actually for? Unless it's for some legal date (such as GDPR) they are fairly pointless and dangerous.

Slow down to speed up

I love Amazon Prime, the service is incredible. I'm amazed that I have items turning up within hours. Last week I ordered something that took several days to come. It's really weird, but when it didn’t come next day I started to get anxious about where it was. I just wanted my new shiny thing.

This is the same for software. A customer is spending a lot of money to get it, and they want it now. Unfortunately this isn't realistic since someone actually needs to write it, but even so, they wanted it now now now. Their expectations need to be managed but I've often found project managers are just unable to say "No" to a customer. Ultimately this means it often falls to the developers and testers to hit an unrealistic (or impossible) deadline.


I'm not a fan of deadlines. They're not very Agile and not very customer friendly. Ideally you'll working with the customer to evolve the software, so when it changes they understand that things will inevitably take longer. In the end they'll get the software they actually want rather than the software they thought they wanted.

What is a deadline actually for? Unless it's for some legal date (such as GDPR) they are fairly pointless and dangerous. This doesn't mean I don't believe in milestones or targets, but just saying that the work needs to be done by some arbitrary date is just ridiculous.


Estimates are a guess, but they often don't take into account real life. People have sick days, holidays, unexpected appointments, etc. Also, if you think about it, no one ever works a full 9-530 on one thing. There’s calls, emails, support, chatting, planning, meetings etc. I bet if you thought about your day you only work 4-5 hours max.


I have Fridays to do R&D, learning, my own projects and the like, but recently we've been so busy that Friday has become a normal day. This is bad, because what Fridays were actually for is contingency. If a project was going out of control, Friday could be used to get it back on track.

Can you go faster?

Unfortunately, one of the bosses at my clients (read that as "someone outside & higher up the project team") has decided that they need their product faster. Well, if they knew anything about Mythical Man Months they would know this is a cause for trouble. If you go faster it is inevitable that corners will be cut and quality will suffer.

Going faster for no reason has no benefit to anyone. You need your PMs or leadership to say No. In fact, isn't this one of the main rules of being a PM? In any industry, when things are rushed it leads to errors. Errors lead to time being wasted by the developer, tester, support, and customer. Often code needs rework and retesting to get it right. That's surely a waste of time in anyones book?

Why not just write it once?

Slowing down has so many advantages. You can learn things during the project. Other projects don't suffer because you have some time to support old work. Ultimatley you're writing code and testing once. This makes the customer happier, you have less complaints and their product is ultimately better quality.

What is the point of this post? I suppose it's just to illustrate what you probably already know. Slow down so that you can actually speed up. Resist the "go faster" mantra because it's quite easily the way to dig yourself, the team and company into a massive hole.