A deadline on its own isn’t a bad thing — I’d even argue it might be good. Usually, I personally perform better with a deadline in mind, and just having an open-ended project can hurt the project in the long run. The key is to find the right balance and to be realistic about it.
Deadlines have to be there for a reason. Just because is not a good reason. It is a horrible deadline practice and can hurt you or your developers. Luckily, most companies I’ve worked for haven’t had issues with arbitrary deadlines, but some have. And let me illustrate a situation I encountered.
I was working at a startup, the front-end team was 3 people, and the back-end team was an equal size. We were working on a new version of the mobile app and a deadline had been set for when it was supposed to go live. However, this deadline was just thought up by the CEO/CTO and there really was no reasoning behind it.
Well, no reasoning isn’t entirely true, the deadline was set based on an estimate of the developers.
If you are a developer, or frequently work with developers, you should at this stage understand what the problem is.
Estimates are estimates, and usually wildly inaccurate. That is not because the developers are incompetent, but because it is incredibly hard to estimate a full project. There are so many aspects that can completely throw off an estimate that you never could’ve predicted.
Anyways, the prediction of the project was the result of a 2-day meeting, going from a brief of the new features, to dissecting every part thoroughly, and then cutting that up even further. Then every part was estimated, cross-estimated, referenced to UX and UI designs, and then all the hours were counted, a margin was added, and there we had our deadline.
And you might think, having UI and UX design ready and including margin in the estimate should be good enough right? That is already much more than most estimates deal with.
Well… no, it wasn’t.
The estimate was somewhere in the range of 3–4 weeks, which is pretty short for a new app release for a small team.
Of course, 2 weeks into the project, and we were behind the schedule. Not because we were slow, or didn’t put our hours in, but because things always turn out differently than expected.
The back-end was busy implementing an API for the mobile app to consume, only to figure out the system couldn’t correctly handle the simple add-on, which meant they had to rewrite a section of the existing API to accommodate for it, pushing the schedule back 2 days for the API endpoint to be done.
And because of the small rewrite, the API would work slightly differently than discussed, leading to a small, few hours’ worth rewrite of a section of the app.
These kinds of rewrites are typical for applications of any size and should surprise no one. However, the deadline was set. And now we were behind schedule.
So what did we have to do? The next day we were requested to crunch an extra four hours to get ahead of the curve again. Four hours on top of a regular working day of 8 hours. Sure, we got free food, but a 12-hour day is never good for your head. But, we managed to get on the track with the deadline again.
A week later, the app update went live. We celebrated the release, someone got some cupcakes as a treat, and then 5 minutes later everyone was behind their computers again pretending nothing happened.
This update had nothing really significant in it that it had to go live that day. Not a single user of the app even knew the update was coming, nor did anyone rely on it (investors/customers/etc). It was a nice feature alright, but would it really have hurt if the update was released a day later? Would it have impacted anyone?
But, it impacted the developers. There was internal complaining between different developers, and the relation between the developers and the higher-ups wasn’t really great.
And this wasn’t a one-off either, it happened frequently. Approximately every other month during the time I worked there.
So what would the take-away from this be? Should you just completely throw deadlines out of the window?
Well, absolutely not. As I mentioned at the beginning of this article, deadlines are usually good, and I actually thrive on them. But they should be targets, not hard deadlines. It should be okay releasing a feature a day (or two) later than estimated. Do you really want to put pressure on developers? Do you think the code quality will remain high during a crunch?
The mentality during a crunch, working extra hours on a workday evening, was, “Let’s get this thing done ASAP.” Sometimes shortcuts were taken so things would work but required refactoring later again. Sometimes these shortcuts were actually put on a schedule to rewrite, sometimes they were forgotten, sometimes the developers themselves didn’t even notice a shortcut was written just because they were tired and wanted to go home.
And when (if) they were refactored, it probably cost more time than the crunch itself. Bugs often were found later in code written during those crunches, and frustrations were high when bugs were found in the production application.
My guess, and I never really measured it so take it with a grain of salt, is any benefit from the crunch was short-term, yes the deadline was met, but the next one was delayed pre-estimation because of rewrites. Developers were less happy (and guess what, developer churn was high), and there were more frustrations overall. And then we’re not even talking about bugs that impacted users post-release.
So how should you do it?
Take your time to do things right, listen to your developers, and make sure to keep track of the progress being made. If deadlines can’t be made and they’re not urgent, postpone! Not with an arbitrary time, but with what is estimated at that point is the delay. Encourage developers to notice risks and delays and bring them to attention. If developers notice something falls outside of the expected scope, they should bring it to the attention of the Product Owner (or whoever manages the team and deadlines), and then the target release date can be adjusted accordingly.
Done ahead of schedule? Well, that is a win-win for everyone! Not only is there more time to properly do QA on the application, but you could also invite the developers to improve the existing codebase.
If you’ve ever worked with developers (or are a developer) you know there are always wishes of improving certain sections of the code. Sometimes it only takes an hour, sometimes it can span several days. Take time to improve what is there and clean things up. Because we all know there always will be messy parts in an application that no one really likes.
Top comments (0)