Deadlines are bullshit.

In software development deadlines are a necessary evil. It is important to understand when they are necessary, and it is important to understand why they are evil.

When are deadlines necessary?

Contractual obligations:

Sales teams often structure deals such that the customer pays more up front than they currently see value for, but promise to increase the value of the product by introducing a new feature the customer can leverage. It is in the best interest of everyone for the company to capture this revenue.

Technical liabilities:

In software we depend on a varying set of uncontrollable external languages, libraries, and technology. Sometimes there are breaking changes that must be addressed, sometimes your entire language reaches the end of its life (looking at you Python 2.7). Sometimes an SSL certificate is expiring on a specific date and it must be rotated before then.

Compliance, government, investors, and other external stakeholders:

It may be the case that in order to remain compliant your team is required to modify the way you encrypt data at rest. Your company may have governmental entities that regulate your industry with deadline driven requirements. Investors in your company may require certain metrics to be exposed to them by a certain time.

What do all of these deadlines have in common?
They are all important. They are all deadlines that cannot be missed. They are all external.

When are deadlines evil?

Your manager says you have a deadline:

While your manager is building out the product roadmap they decide to ask you for estimates. What do you think the timeline will be for this feature? They will use this to set a date to expect the feature to be wrapped up by.

Your software development methodology says you have deadlines:

Scrum, agile, waterfall, kanban, whatever random thing your new project manager thought up over last weekend. Most of these methodologies will require engineers (or worse, non-engineers) to tag work with estimates and those estimates will be used to make deadlines for the work to be completed by.

What do all of these deadlines have in common?
None of them are important. They are arbitrary. They are all internal. They are all bullshit.

If you work for a software consulting firm, freelance, or do similar work that is scope limited and repeatable on a per-client basis you can stop reading here. All of your internal deadlines are also external deadlines by construction, and therefore necessary.

Further, many of the drawbacks of internal deadlines cease to exist when doing scope limited and repeated work which is why it is important for consulting firms to use them to their advantage.

Why are internal deadlines evil?

There is a heavy cost to instituting a deadline on a piece of engineering work.

Estimation

The initial cost is in the work estimation phase. When estimating engineering work a substantial time investment is required by an engineer in order to get an accurate estimate. If that time investment is not put in the estimate will certainly be wrong. Sadly, even if the engineer does put in the effort to get a proper estimate it is still possible to be wrong.

Misaligned Incentives

There is an incentive to lie and give estimates much longer than the feature is truly expected to take. This incentive comes from poor performance being tied to missing deadlines. Over time it will appear that more disingenuous team members are performing better, when in reality they are just more likely to lie about their estimations.

If an estimation turns out to be wrong and the deadline is not likely to be hit there is an incentive to cut corners in the code base to meet the deadline. Some examples would be skipping writing automated tests, or avoiding a necessary refactor and adding to tech debt instead.

Another way engineers are incentivized to exploit this system: If they finish a feature early they can delay releasing it until the feature deadline comes up.

Low Morale

Since estimating software is extremely difficult outside of the consulting and freelance realm, deadlines are likely to be missed often. Repeated failure has a cost to the morale of the team.

Micromanagement

Deadlines are wielded by middle managers as a whip to harass and annoy engineers working on features. They ask for updates, they want daily stand-ups, they want to know everything about your day-to-day. It is just the modern formulation of a very common tactic, micromanagement.

High Stress

When engineers feel the pressure of other stakeholders holding deadlines over their heads it creates an environment of high stress. The engineers in this environment do not feel trusted, and they do not enjoy working for the company.

High Turnover

The cumulative effect of all of these costs ends with the highest cost of them all. High turnover. On teams with high turnover rates the best engineers have an easy time finding new work and leave quickly, the worst engineers have a difficult time finding work and remain. This selects for a lower quality team over time.

Conclusion, Resolution.

None of the drawbacks of internal deadlines are in the best interest of the company. Over time the team gets worse, burns out, completes less work, is more likely to house disingenuous characters, and the code base gets worse.

The resolution is simple. Never have internal deadlines. Operate on a prioritized and ordered list of features. Estimate only when necessary to prioritize and do so in a t-shirt sizing  way. Trust your engineers and they will begin to love their work. Engineers who love their work are happy and productive.