.png)
1 week ago
7
Do not rush software development.
Not even when a deadline approaches. Especially not when a deadline approaches.
Strive for consistent, persistent progress, not bursts of emergency-driven coding. When a deadline looms ahead, let it wash over you. The time to deal with that deadline lies in the past, when you still had many levers to pull. The closer you get closer to GM day, the fewer choices you get, and the more you simply have to execute the plan, however poor it looks.
Whatever you decide to do to meet a deadline, do it in a calm, deliberate manner. Don’t rush, don’t scramble, don’t cut corners. If you have to take on technical debt to meet the date, discuss it with your team and ensure buy-in. If you have to work longer hours, do it knowing exactly how much extra you’re putting in, when you will stop doing it, and what you realistically expect to get from the exercise. The return on overwork is not as great as you think.
Hitting a deadline is a shared responsibility, but it’s not shared in equal proportion. Many signals are available to project managers and program managers along the way to understand the risks of a project. The team’s ability to not miss a deadline is greatest at the beginning of the project, and smallest near the end. Therefore, short of gross negligence or sabotage, the responsibility to deliver a project on time lies on those who define and manage it, not the people who actually implement the product.
Also, all deadlines are made up.
