Accurately estimating the time required to complete tasks or “tickets” is a complex endeavor. Every time you break down and plot out how you are going to add a new feature to existing software what you are really doing is…. making a wild-ass guess!

Yes, I could say that adding a new rails controller is really simple and will take only 5 minutes. It is just rails g controller Model. But, you will probably want to write some tests for that, and get it code reviewed, and have the product manager look at to see if it works how they want it to, etc, etc.

Even if you are coding by yourself we programmers tend to underestimate how long a task will take and don’t always consider the full scope at first.

How to tame the estimates

Dealing with this complexity in estimation takes a willingness to account for the uncertainty. One common way to do this is to use a “safety margin” — a buffer in our estimates that accounts for unforeseen challenges and delays.

This can be as simple as saying that a task will take 2-10 days instead of 5 and accounting for the 10 days. Doing this will leave plenty of flexibility in the schedule (and you can always add more stuff in later!). Incorporating a safety margin is not just about padding timelines; it’s a strategic approach to ensure project resilience and sustainability.

Since software projects are inherently uncertain due to various factors, such as changing requirements, technical hurdles, and team dynamics, a task that initially appears straightforward, estimated to take two days, might evolve into a ten-day endeavor as complexities unravel. This variability is normal in software development, but it necessitates a flexible and understanding approach to project management.

A safety margin is an acknowledgement of uncertainty. It’s a planned buffer period that allows for the absorption of unexpected events without derailing the overall project timeline. This buffer is crucial not just for dealing with technical uncertainties, but also for accommodating human factors like creativity, learning curves, and the need for quality.

The Woe of Ignoring the Safety Margin

Without a safety margin, there’s a high risk of deadlines being missed as soon as any task takes longer than its initial estimate. This not only stresses the development team but can also compromise the quality of the work produced, leading to further delays and costs down the line.

Leaders or managers who push for all tickets to be completed within the most optimistic timeframe, often by implicitly or explicitly expecting unpaid overtime, are taking a short-sighted approach. While jerks might think this is a way to maximize productivity and meet aggressive deadlines in the short term, the long-term effects suck for everyone involved:

  • Burnout: Continuous pressure and long hours can lead to team burnout, reducing productivity and increasing turnover.
  • Mounting tech debt: Rushing to meet unrealistic deadlines often means cutting corners, leading to bugs, technical debt, and a product that fails to meet user expectations. Or just product that ends up failing! I’ve seen big complex projects fail for many reasons and tech debt is right up there as a leading cause of death (or rigor mortis).
  • Trust: Overly aggressive timelines can erode team morale and trust in leadership, as team members feel their well-being is undervalued. This is a big one. Programmers are knowledge workers and are, by definition, not stupid. Treating them like they are stupid will just blow up in managements face.
  • Sustainability: A culture that regularly relies on unpaid overtime and disregards safety margins is not sustainable. Over time, it can ruin the organization’s reputation, making it a pariah in the talent market.

Building a Sustainable Approach

Incorporating safety margins is part of a sustainable, long-term strategy for software project management. It requires an understanding from leadership that good work takes time and that the unpredictable nature of software development cannot be forced into overly optimistic timelines without consequences. It also requires that leadership isn’t of the opinion that human beings should be pushed as hard as possible to ship code at all cost.

I wrote this article not to emphasize the procedural magnificence of building in some safety margins to estimates. The idea of a a system having safety margins being a good thing should be obvious to anyone who has crossed over a bridge without worrying if it is safe enough, or strong enough. The main point of this article is to emphasize the reasons for the safety margins so that we can recognize the callous decision makers who ignore the idea.

Any reasonable boss will understand that hard working, diligent people can do their best and still not have a exact timeline of how a project will pan out. The safety margin is about guarding against ass-hat bosses who drive developers like cattle as much as it is guarding against our own uncertain estimates.

Adopting a realistic and humane approach to project planning—acknowledging the true complexity of software development tasks, respecting the team’s work-life balance, and prioritizing quality over speed—benefits not just the team but the project and the organization as a whole.

Ultimately, the safety margin approach leads to healthier teams and superior products which is a core goal of any functional and healthy team dynamic.