Stop hating timelines, and gain inner peace

Recently on Quora someone asked "As a senior developer, how do you handle being behind your estimated time or deadline?", and I was nerd sniped. I had to answer. Here's my answer on the topic :)

Some initial guidance to giving estimates:

  • First and foremost, stop hating timelines/estimates - they’re actually pretty good for driving focus for yourself and others around you. If a project is totally open ended I often would spin my wheels making the most perfect subsystem when its just not useful.
  • Creating good estimates requires practice, just like coding
  • Most engineers have pride/get attached to their estimates. This is good, but also what causes stress.
  • Communicating a date move, and communicating project status is also a skill to practice
  • Very rarely in software development is there an actual reason to stick to be attached to a specific date. Most organizations I’ve been in understand that, and yet engineers get stressed about dates that they estimated themselves.

How to make a good estimate:

  • Step 0: Break down to work into its component pieces, especially considering the parts that will take the longest. Throw a number of “dev days next to each item”. Add 20–25% to the total number for QA and mishaps. For me, this is usually enough to hit most dates.
  • Step 1: Take a couple days to test the waters on the expensive/risky parts of the project to understand feasibility while also getting a little work done. Tell people you’ll have an answer in a couple days. Adjust timelines based on what you’ve learned.
  • Step 2: After you’ve validated a little bit, come back and say: “the estimate for the given work is something on the order of N weeks or N months, ±20% of the original timeline. We can go faster if Y is different, we’ll go slower if we need to do Z. Then say the estimate is ambitious and its good to be ambitious.
  • Step 3: Provide regular updates highlighting how you’re tracking or not tracking against the the original estimate providing more specificity on release date the closer you get.

If you’re not going to hit the estimate:

  1. As soon as you feel like you’re probably not going to make it revise your timeline and let the stakeholder know

That’s it, it’s easy, no one cares honestly.

Parting thoughts

Consider what these timelines mean. Are there hard external timeline dependencies? If not, everyone should be fine with moving the date, and in my experience, honestly no one cares about a date move. What’s 2 weeks or a month compared to the lifetime of a company and compared to the successful launch of some product. The amount of time I’ve seen fellow engineers stress on a date move for a date they created is way too often. Stress comes from within not externally, usually. Generally, all people want to know is how its going and that you have things under control.