Workers who do not know the deadline, especially the phrase "Deadline is the first productive force." The deadline itself is not a problem. In many cases, it can indeed increase productivity, but the deadline needs reasonable reasons to support it. "Just because" (no other reason) is not a good reason, it will bring harm to developers.
Rene Pot, a JavaScript developer who started programming at the age of 12 and has more than ten years of development experience, described his experience.
Rene Pot's narrative: Unreasonable deadlines hurt me
I used to work in a startup company, when there were only 3 people on the front-end and back-end teams. We are developing a new version of a mobile app, and of course the company has set an online deadline. However, the deadline is set by the company's CEO/CTO for insufficient reasons.
Of course, it doesn't seem right to say that it is completely unreasonable. The deadline setting should be based on an estimate of the developer's ability.
If you are a developer, or often cooperate with developers, you should understand the problem: "estimate" is only an estimate, usually not accurate. is not that the developer is not capable enough, but that it is very difficult to estimate the entire project. Many unexpected factors will completely subvert your pre-estimation.
The prediction of that project at that time was the result of two days of discussion. The meeting discussed new features and thoroughly decomposed each part. Each part has been estimated and cross-estimated, UI and UX design has been completed, the required time has been calculated, plus some buffer time, and finally got the deadline.
You might think, now that the UI and UX design has been completed, and the buffer time is also considered, this estimate should be pretty good.
However, it is not.
The final development time is estimated to be 3-4 weeks, which is not sufficient for new app release projects of small teams.
Indeed, two weeks later, the progress of the project has been unable to keep up with the schedule. The reason is not that developers work too slowly, but that things often develop differently than expected.
When the back-end team implemented the API of the mobile app, they found that the system could not properly handle simple add-on components, which meant that they had to rewrite part of the existing API, which resulted in the completion time of the API endpoints being delayed longer than expected. Two days later.
Due to the rewrite, the operation of the API was slightly different from that discussed in the previous meeting, which in turn caused the team to rewrite part of the app, which took several hours.
This type of rewriting is common practice for applications of any size, and it shouldn't be surprising. However, this project has a deadline! Now we are behind.
what can we do about it? The next day we were asked to add 4 hours to the original 8 hours of work. The company provided meals for free, but the workload of 12 hours a day was too much. However, we finally caught up with the progress.
A week later, the app was updated and launched. But we were not particularly excited. After a short celebration, we went back to the computer, as if nothing happened.
The update is not too powerful, but it must be live that day. Even users don't know that the app is updated, and no one depends on it. The new features are really good, but will there be any impact if the update release time is delayed by one day? Will it hurt anyone?
Rather than completing the project according to the deadline hurts the developer. Developers complain to each other, and their relationship with leaders is also affected.
And this situation is not accidental, but often happens.
So what lessons do we learn from this? Abandon the deadline altogether?
of course not. Deadline itself is a good thing, but should be a goal, not a rigid line . The new feature release time is one or two days later than expected without any harm. Is the product owner really going to put so much pressure on the developers for the deadline? Can the code maintain high quality under overtime conditions?
In particular, the psychological state of the developer in the overtime state is likely to be "hurry up and finish this." Sometimes developers even choose to "take a shortcut". The work seems to be temporarily completed, but it needs to be refactored later. Sometimes these "shortcuts" will lead to rewrites, and sometimes they will even be forgotten. The developers themselves may not notice these shortcuts because they are too tired to write and just want to go home.
If the shortcut needs to be refactored, it means more time. In addition, the code written during overtime often has bugs, and the frustration of developers will increase after bugs are found in production-level applications.
I think that the benefits of overtime work are short-term and seem to have caught up with the deadline, but what about the next one? Due to the possible need to rewrite, the next deadline will lag behind expectations. The developer's sense of happiness decreases and frustration increases. This does not include bugs that may affect users after the version is released.
How to change?
The person who sets the deadline should spend their time doing things right. They need to listen to the developers and track the progress of the project. If the project progress is behind the deadline, and the project itself is not urgent, postpone it! Of course, postponing does not mean an indefinite period, but to re-estimate the project time at the current node. Encourage developers to pay attention to risks and delays, and inform the project leader in time. If developers notice that something is behind schedule, they should inform the product owner in time, and then the person in charge will adjust the release date according to the specific situation.
What if the project is completed ahead of time? This is of course a good thing, and it is a win-win situation for everyone. First, this leaves more time for QA. Second, the product owner can also ask developers to improve the existing code base.
deadline, I want to say that loving you is not easy
After Rene Pot's article was forwarded to reddit, it caused a lot of discussion.
Someone quoted the famous quote of the British author Douglas Adams: "I love deadlines, and I love the whistling sound they make when they fly by."
Some netizens joked:
Without a deadline, how do I know when to start working?Without a deadline, how do you know when you can stop working?
However, in the comment area, there are more complaints about setting deadlines at will, and even a "fishing guide" appeared:
I generally ignore the sprint (sprint) plan, many tasks are not enough for a week. And as of now, I have not been fired.The sprint plan is actually: require you to complete the task before the deadline, so that when you do not complete it, you will work overtime because of guilt. The solution is to throw the deadline back to the person who made it.
As a developer, what kind of deadline do you think is reasonable, and what kind of deadline brings harm. Please leave a message to tell us.
Reference link:
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。