Software Engineering and Deadlines

It's no secret that software engineers hate deadlines. But that doesn't mean deadlines are a bad thing. The reason software professionals hate deadlines is pretty simple: it's really hard to predict how long it takes to invent something.

Bugs

In the case of fixing a bug, giving a deadline is like visiting a doctor and telling them you need to feel better by Saturday before they've even started the checkup. How could the doctor possibly know how long it will take to cure you? Without knowing any symptoms, vitals, or any other data, no doctor would pretend to know how long it would take to discover, diagnose, and treat an unknown ailment. Giving software engineers deadlines for bug fixes is certainly a major pet peeve in the industry.

Features

In the case of building new features, there is often a level of innovation required that the team hasn't ever built before. Building a new feature can often be compared to architecting and constructing a new type of skyscraper that's never been done before. Depending on how similar the design is to other projects you've worked on you might be able to ballpark a timeline (and experienced engineers can). But if the project varies from anything you've done in the past you'll have a very foggy idea about its duration.

Software engineers hate deadlines. But maybe that's just a misunderstanding.

Everyone's Goal

In reality, stakeholders and software engineers have the same goal: to make money for their organization.* What software engineers need to understand is that their paycheck is an investment that their employer makes and it needs to yield a return.** For example, if we can estimate that building a new feature will take one engineer one month, we can estimate the amount of revenue/savings the organization needs to gain from the project in order to reach its desired ROI. Will the project bring in more money than that engineer's monthly income? How much more? Is it a bigger return than the organization could get by putting that money in another project? In another investment? In the stock market?

How should organizations manage scope and deadlines?

As always, collaboration is key. Stakeholders cannot determine new features and delivery dates in a vacuum. Similarly, engineers don't have the information necessary to determine how long a project can take and still be valuable to the business. Stakeholders and engineering leadership have to make these decisions together. In one scenario stakeholders may ask for a specific scope of work to be done and the engineering leadership could provide an estimated delivery date (not a precise deadline). In another scenario, stakeholders may ask for a product/feature to take to market by a certain date and the engineering leadership could define what amount of work could be done by that time. Problems arise when stakeholders try to define both. Different problems arise when engineers define both. In some cases a hard deadline may be required to get to market on time or prevent the consequences of an audit. In many other cases an estimated delivery date is more appropriate than a hard deadline.

When working together to define scope and timeline, real value can be added to the business in predictable increments. When these two things are not collaboratively determined at the leadership level, we're mostly throwing money at the payroll expense account hoping it will sprout new revenue.

* Yes, there are some altruistic non-profit and philanthropic organizations that do not have the goal of making money. The same principles apply to these organizations, though they optimize for things other than profit. They may optimize for shelters built or first aid kits delivered or greenhouse gases prevented. In any case, the need for an ROI still stands, but is just measured differently.

** There are scenarios in which even for-profit businesses do not need an immediate financial return. For instance, many high-priority projects are for the sake of risk mitigation. At some level, though, a value can be placed on even those kinds of projects if we determine the likelihood the risk will impact the business and the loss that would be incurred.