Deadlines in themselves are not a bad thing, I would even say, somewhere good. Personally, my work turns out to be more productive if I mentally focus on some time frame, and when a project has no time frame at all, it can ultimately hurt it. The main thing here is to think realistically and maintain a balance.
The deadline must be justified. “Because because” is not justification. This is a bad time-setting practice that affects both companies and developers. I was fortunate that most of the companies I worked for didn’t have the habit of picking deadlines. But there have been exceptions. I want to talk about one situation of this kind as an example in this article.
I was working at a startup back then; Our front-end team consisted of three people, and there was also a back-end team of the same size. We were working on an updated version of the mobile application and had to meet the release before a clearly marked day. One problem: this day was arbitrarily chosen either by a simple director, or by a technical one without any reason for such a decision.
Well, that is, not entirely without justification - when choosing a day, the approximate duration of the work declared by the developers was taken into account. If you work with code or with the people who write it, then you probably already understand what the problem is. The approximate dates are always approximate, that is, they are very different from what actually comes out. And it's not about the incompetence of the developers, it's just incredibly difficult to estimate the amount of work on an entire project. There are many things that can shift deadlines and that are impossible to predict.
One way or another, our rough estimate was the result of two-day meetings: first, a general overview of new functions, then a detailed analysis of each separately, then an even more detailed analysis ... Finally, for each stage of work, we estimated the number of hours, rechecked, correlated with UX and UI design, they put everything together, threw some hours on top - and that was the deadline for the work.
You are probably now thinking: well, since their UX and UI designs are already ready, and even more hours are laid in reserve, then, probably, everything should go fine? In most cases, the conditions are worse when setting the dates. Well, in general, no. Nothing went fine.
The duration of the work was set at three to four weeks - not too much time if we talk about the release of a new product with a small team. Of course, after the first two weeks, we were already behind schedule. Not because they worked slowly or spent few hours on the project, but because everything always goes wrong.
The backend was poring over the implementation of the API for the application, when it suddenly turned out that the system could not interact normally with a simple add-on, which means that it was necessary to rewrite the already prepared API fragment taking this circumstance into account. It took two unscheduled days to finalize the endpoint.
Because of this small change, the API began to work a little differently than it was supposed at the discussion stage, which led to the need to rewrite individual parts of the application - a work for several hours. Rewriting like this is common in mobile apps of all sizes, and shouldn't surprise anyone. But we have a tight deadline. And now we can't fit.
So what can you do? The next day, we were told that we had to work four extra hours to get ahead again. Four hours on top of a typical eight-hour workday. Well, yes, we were fed, of course, but there is nothing useful for the brain in such twelve-hour shifts and cannot be. Nevertheless, we managed to catch up and keep up with the schedule.
A week later, the application was released. We were glad, someone brought some cupcakes to celebrate, and five minutes later everyone was already sitting at the monitors and pretending that nothing had happened.
There was nothing so important in the update that would motivate the need for a release on this date and not a day later. None of the users knew that a new version was being prepared, no one (neither clients nor investors) made plans based on a date. Yes, the features are useful, but would anyone feel worse if they were released one day later? Would it affect anyone at all?
But the developers affected. Here and there people poured out their displeasure to each other; the relationship between the team and the management was clearly spoiled. And this is not an isolated case, this happened often while I was working there - with a frequency of about once every several months.
And what is the conclusion from all this? Give up completely at any time? Well, of course not. As mentioned at the beginning of the article, deadlines are actually useful, and I myself find it easier to work with them. But they should be taken as guidelines, not as rigid commitments. If the product comes out a couple of days later, it shouldn't be considered the end of the world. What's the point of putting unnecessary pressure on developers? Or do you think the quality of the code does not suffer from such marches?
When we worked out additional hours after a working day late in the evening under the banner of force majeure, the general mood was: "So, we need to finish it off as soon as possible." Often all sorts of crutch solutions were introduced that would work for a while, and then require refactoring. In some cases, the corresponding refactoring was immediately scheduled, in others it was safely forgotten. And it happened that the developers themselves did not really realize that they were doing something crutch, because they were tired and wanted to go home.
When it comes to refactoring (where it came at all), it is probably more of a resource than force majeure itself. Bugs began to appear in pieces of code written in a hurry. Since the app had already been released, it got on everyone's nerves especially.
According to my estimates (I did not collect statistics, so I cannot vouch), this processing was useful only in the short term. Well, yes, we released the application on time. And the next release already had to be delayed, because a lot was being rewritten. The developers were unhappy (and, you guessed it, they were actively quitting), the atmosphere in the team became tense. And we still do not take into account the consequences of the bugs that users encountered after the release.
How do you need it?
If you want everything to be done efficiently, do not get into a fever, listen to the developers and be sure to track progress. If the team does not fit and there is no reason for urgency, move the deadline! Not arbitrarily, but for the time that is not enough at the current stage. Encourage developers to communicate potential causes of delays and risks. If someone sees something that clearly does not fit into the general schedule, it is worth drawing the attention of the person who is planning, so that he has the opportunity to correct the estimated dates.
Did you do everything ahead of time? Well, in such a situation, everyone only wins. And testing can be done properly and give developers the opportunity to improve something in the codebase. If you are a developer or communicate with developers for work, then you yourself know: there are always places in the code that you would like to tighten up. Sometimes it only takes an hour and sometimes it takes several days. It's better not to waste time on making the code better and neater - as we can all confirm, there are enough shortcomings in applications that none of the users will appreciate.