I think Sean often overplays politics. The most important thing in any project is whether or not it achieves the goal that the overall business has for it. And your job is always to increase the probability of that happening as much as possible. Sometimes it requires politics and sometimes it just requires getting to the task at hand.
How I estimate work
101–110 of 326 posts
Re: How I estimate work
#102> For instance, many engineering teams estimate work in t-shirt sizes instead of time, because it just feels too obviously silly to the engineers in question to give direct time estimates. Naturally, these t-shirt sizes are immediately translated into hours and days when the estimates make their way up the management chain.
This is mostly fine when it’s the tooling that does the translating based on rolling historical averages - and not engineers or managers pulling numbers out of their rear.
Re: How I estimate work
#103After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project wa…
This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate. I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
You estimate your best and then during the project the people who keep changing the spec every two weeks ask why the deadline is slipping.
Re: How I estimate work
#104Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it…
I prefer 1 hour/1 day/etc but yes, this is the only method that I’ve found to work. Be very clear what result you’re trying to produce, spec out the idea in detail, break down the spec into logical steps, use orders of magnitude to break down each step. There’s your estimate. If you can’t break it down enough to get into the 1 day/1 week range per step, you don’t actually have a plan and can’t produce a realistic estimate
Re: How I estimate work
#105Earlier quoted context omitted.
I agree. Software engineering is basically the only industry that pretends this is professionally acceptable. Imagine if government staff asked when a bridge would be done or how much it would cost and the lead engineer just said "it's impossible to estimate accurately, so we wont. It's a big project tho". Estimating in software is very hard, but that's not a good reason to give up on getting better at it
Government contractor's estimation is based on what number is politically acceptable, not how much the project would realistically take. 90% of public projects were overbudget [0]. But you're pretty spot on, as 'professionally acceptable' indeed means politically acceptable most of the time. Being honest and admitting one's limit is often unacceptable. [0]: https://www.strategy-business.com/article/Why-do-large-proje…
Yes, my claim is absolutely not that they're good at it haha.
Estimation is a real problem in a lot of industries, including ours, and I think that's probably common ground here -- I suppose my differing position is that I think the solution is to get better at it, not to refuse to do it.
I've been on projects where I've seen the budget explode and projects where I've seen the budget kept tight and on track. The latter is very hard and requires effort from ALL sides to work, but it's almost always achievable.
I actually empathize a little bit more with megaprojects because generally the larger the budget the harder it will be to keep on track in my experience. Most estimates we're asked to give in our day jobs are not even multi-million dollar estimates.
Also I'm using budget and estimate interchangeably but these are of course different things -- that's one of my nitpicks is that we often treat these as the same thing when we talk about estimating being hard. A lot of individual estimates can be very wrong without affecting the ultimate budget.
Re: How I estimate work
#106One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engin…
Anyone from a sales roll care to speak to this?
Really interesting topic. (I’m actually somewhere in between sales and dev - doing Req. Engineering, Concepts and planning).
Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes.
And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.
Re: How I estimate work
#107After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project wa…
This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate. I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
It's definitely unfair in a sense. But companies that make over-extrapolated roadmap estimates from not enough evidence systematically outcompete those who don't, because their customers greatly prefer companies who give a date and then try their best to hit it over companies who say they don't know when the product will be ready for X and you'll just have to wait and see.
Re: How I estimate work
#108Surprised multiplying by Pi hasn't made it here.
Multiply your estimate by 3.14159 until you find the actuals and your more accurate estimating coefficient.
https://news.ycombinator.com/item?id=28667174 (2013)
original: https://web.archive.org/web/20170603123809/http://www.tuicoo...
Re: How I estimate work
#109After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project wa…
Yes, the key part of estimation is not that we need to say how large must be the (time) box to contain the project, but rather how much of a project can we pack into a box no larger than what the business could bear.
Hence the separation into must-haves, highly desirable, and nice-to-haves. Hence the need for modularity and extensibility: you if don't get to build everything in one go, and can't always even predict what parts would be left outside the scope, you have more of a lego-like structure.
BTW maybe if we finally shook off the polite lie of planning how much work a project could be, and instead started to think in terms of possible deliverables within different time frames, the conversation would become saner.
Re: How I estimate work
#110Earlier quoted context omitted.
The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development. 1. Think about what product/system you want built. 2. Think about how much you're willing to invest to get it (time and money). 3. Cap your time and money spend based on (2). 4. Let the team start building and demo progress regularly to get a sense of whether they'll actua…
How would you decide between doing project (a) this quarter, or project (b)? If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI. To rationally allocate money to something, someone has to do the estimate.
The exact same way you'd treat any other investment decision.
In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.
You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.