Contra my optimism on software estimates, some realism:
I gather as much political context as possible before I even look at the code. How much pressure is on this project? Is it a casual ask, or do we have to find a way to do this? What kind of estimate is my management chain looking for? There’s a huge difference between “the CTO really wants this in one week” and “we were looking for work for your team and this seemed like it could fit”.
Ideally, I go to the code with an estimate already in hand. Instead of asking myself “how long would it take to do this”, where “this” could be any one of a hundred different software designs, I ask myself “which approaches could be done in one week?“. – Sean Goedecke, How I estimate work as a staff software engineer
Folks with the best intentions have asked me “How long would this project take? Please say two weeks, that’s how much time we have.” Well maybe I embellished the second part. Point is, too often I interpreted this as asking the question, and not asking for an answer in the time-is-scarce context we were actually operating in.
We often didn’t like the answer. Too much scope cut to fit in their time frame (aka appetite) or not enough detail to decide where to trade scope for time.
In other words, I don’t “break down the work to determine how long it will take”. My management chain already knows how long they want it to take. My job is to figure out the set of software approaches that match that estimate.
Sometimes, you make your coin by delivering exactly what was asked for, sometimes you make it by solving the problem in a novel way. Every so often, you make it by saying no and choosing to do something with better trade-offs.