In 50 years of programming I found:<p>(a) time estimate are dangerous. In one case the leader of our team estimated 5 people for 5 months. The company wrote a fixed-cost contract. After 10 people for 18 months the company folded.<p>(b) time estimates are meaningless. All of the software I worked on was new. There was no "prior art" to ground the estimate. Projects were almost always "late", mostly due to changing requirements.<p>(c) time estimates assume a known future. Who expected the pandemic? (Or the Spanish Inquisition?). How good is your estimate when the 6 people you could "hire" are all rejects from other projects because they can't program?<p>(d) time estimates assume a known good tool set. CorelDraw won't run on your old Mac but the company won't pay for new hardware. Microsoft pushed out a "destruction tuesday" update and now your machine won't boot. Somebody "upgraded" the library software and now your code won't compile. And don't get me started about chasing a compiler bug (I've fought 5), each costing an unplanned week. Or hardware bugs (3 times), that basically stopped the project until they were fixed.<p>(e) time estimates will cost you time and money. Suddenly everything become a crisis. Cancel that vacation. Work nights. Work weekends. Nobody gets a raise if this is late.<p>(f) time estimates WILL be used against you. Managers write down the "estimate", stick it in a drawer, and when "blame time" comes you can be certain to be "to blame" for a bad estimate.<p>I know you think I'm wrong. You "just know" my "lived experience" is nonsense.<p>You can't estimate software. Get over it.<p>Read "The Mythical Man Month".
Estimating is really hard. It's not something I've had to do until my current role leading frontend development efforts.<p>It takes me several days to come up with a plan of action for planning several months of work for the team. In this action plan, I map out every task that needs to be done, and figure out which tasks that can be done in parallel. Which ones have dependencies on each other. How to prioritize features that matter first. Which things need more discovery. Which features are high risk and how to mitigate. How to do a progressive demo to the stakeholders while still leaving time to tackle tech debt. How to divvy up tasks efficiently between teams so resources are utilized properly.<p>The article captures my thought process on time estimation. Being able to make an estimate, and deliver on it, can really drive your career. Businesses almost always have a hard deadline. You have to be able to put yourself in everyone's shoes but with enough practice it's not so bad. Being able to commit to this plan let's you have conversations to deviate or adjust as needed. No estimations are ever 100% accurate, but getting something close makes planning each sprint significantly easier
Gergely Orosz captures extremely well my thinking regarding time estimation. Being able to provide time estimation is a skill you should practice and improve. It will help you improve your project management skills and your communication skills. It will help you set more explicit expectations early on. It will help you deal with risks and how to mitigate that. It will help you build trust within the organization. The tradeoffs are essential: "Pushing back on estimates also misses the bigger point about engineers staying focused on delivering the largest business value... For every major project, we shipped something different on the launch date, than what we agreed to originally". Like everything that is important, people (Dilbert type of managers) will find ways to abuse it. When that happens, find a better place to work at. Don't sacrifice your ability to learn, grow, and increase your impact.
This piece seems to be missing a key idea of the #noestimates movement: that it’s possible to forecast delivery dates without estimating.<p>Whether that’s true or not is open for debate—personally, I think the #noestimates folks are just replacing estimating with story splitting, which is essentially the same work—but by missing this point, the article is a rather long fight with a straw man.<p>Admittedly, when I saw the straw man, I started skimming, so I may have missed something important in the article.