Software estimation is hard – do it anyway
jacobian.org
jacobian.org
I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it.
The process will require dev resources, business resources and probably people from the support team and will take a lot of time.
I'm happy to do it. It's actually my favorite part of the job. But the business invariably doesn't want to spend the time and money to do that.
They'd generally much rather start with a fairly vague description of what they need and let the devs keep throwing stuff against the wall and see what sticks.
Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.
"Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. One goes into the first room, and it’s dark, completely dark. One stumbles around bumping into the furniture, and gradually, you learn where each piece of furniture is, and finally, after six months or so, you find the light switch. You turn it on, and suddenly, it’s all illuminated. You can see exactly where you were." [1]
[1] Source: https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...
However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all:
https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...
Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint.
On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements.
This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.
Yes, exactly. The code is a technical specification that is so clear that a very dumb uncreative machine can follow it perfectly!
Start at the high end, will it take... years: NO quarters: NO months: erm... NO. weeks: maybe days: Unlikely hours: Ha. No.
So you end up with a range (days?-weeks-months). That's too broad, what could go wrong to avoid making it months long project (well we could investigate X, Y, and watch for Z). What needs to go perfect for it to be days? (well we could... wait, days is unlikely).
Those discussions about the high and the low to get "reasonable" confidence are super important.
The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points let compare two tasks. If you try to give t-shirt sizes points (e.g. "M = 2*S"), then you might as well skip the t-shirt abstraction and just use story points.
Doing the bulk of your planning during a 2-3 day PI Planning event lets a lot of people dive into a few things, preparing an estimate for the coming quarter, mapping dependencies across teams, lining them up with other planned work and outlining risks to the plan. Then the developers get to explain the plan to upper management, discuss any potential revisions and get moving...with everyone on the same page.
This also keeps any estimation beyond the current quarter firmly in the realm of subject-to-change.
That's the most critical part of it. Tech people and business people being out of alignment on expectations is where everything goes sideways and all of the friction comes from.
Out of all of the methodologies I've come across in my career, this is the only approach I've seen that really balances development realities with a level of "enough" future planning to help business people make informed decisions.
There are too many people involved to just skip it to keep working.
"How about we do it that other way. You mentioned devs could keep throwing stuff against the wall. I like how that sounds."
This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently.
Of course it could be true in your case, but you can't blame the inability of software engineers in general to estimate tasks on that.
In internal business app teams, the sticky issue is that no one actually understands the business problems well enough to articulate sufficiently. There's usually very little incentive to be the spec person, on either the technical or business side.
It might often be the same underlying issue. The difference with rewrites is that the "conversation" happens within tech teams, no outside player.
When someone proposes a rewrite for software, I ask him or her to think critically along the following questions:
1) What is the purpose of the rewrite? What do you hope to accomplish by it? What business objectives are furthered by the rewrite?
2) Explain in detail what is wrong the the existing code base, and why it is untenable to fix those problems piecemeal.
3) Explain in detail how the rewrite will avoid, overcome, or improve significantly on all the problems mentioned in 2).
In my most recent, case, and as I expect in many others, I couldn't convince anyone to engage on any of these questions.
For 1), we were told that the org planned to build significant new features on the product and the rewrite will help. However, the company's priorities changed significantly even as the rewrite was just getting started. By the time I left the company, I was not aware of any short or long-term plans to continue adding functionality to the now-rewritten product.
For 2), the level of detail was along the lines of "the code base is awful. I hate it!" And, that's about it. Question 3) is, of course, impossible to answer if you failed to answer 2).
Failure to be able to answer these types of questions is also in my eyes a strong indicator that you don't understand the existing product very well. And why would we? The existing team that built the thing had all left by that point, which is, in my experience, the norm, not the outlier. It's normal for devs to build something for a few years and then peace out, either via an internal transfer to another team or a new job opportunity.
I believe that much of software is knowledge acquisition, and much of the cost of software maintenance is in dealing with the failure to transfer and maintain acquired knowledge over time. Rewrites can be spurred by ignorance, and that same ignorance can lead to the rewrite taking much longer than expected.
If the old code is a perfect specification, there is no need to rewrite it, because you already have a code base that performs to specifications.
Less glib, random code is a terrible format for specifications, because it contains lots of things that aren't actually requirements of the specification, but implemenntation details. And a specification that contains lots of specific things that aren't actually part of the specification is not a good one.
This is precisely why rewrites fail!
I've never seen a rewrite where the devs had a perfect understanding of what the old code was doing. They understand the happy path, probably. Not the millions of edge cases through the years.
They only learn the requirements after knocking out the easy stuff and then getting into the gritty bits of bringing over all the edge cases that didn't fit their new mental model easily.
...Or you can spend that 6-12 weeks just estimating, involving more time by more people, have only a somewhat-better idea of how long the first set of features will take, and no working software to show for it.
In practice, however, I find few businesses willing to either have a 1.5-3 month estimation window, or to start development with none but a wildly vague estimate, amounting to a guess, waiting 1.5-3 months to find out what a somewhat-accurate estimate may look like.
> It requires buy in and input from the entire business stack.
- Inaccurate estimates don't matter: there is so much wack-a-mole going on that by the time you're done it just doesn't matter as everyone is 3+ focus hijacks removed from when you started.
- Accurate estimates cause heartburn: they wanted it weeks ago and now you're showing up with a number far larger than anyone wants to hear, but they can't tell you where to cut scope.
Everyone has to do the dance or it's just no fun.
And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is:
"We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build."
Stating it like that usually makes people realize how ridiculous it is to commit to something, but you don't know what, but you'll still do it by a certain date. And it makes them feel like you're being willing to work with them/gives them some decision making power.
The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'.
I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken.
But... fortunately, I've not had project work like that in a while :)
For contract work you have to do the process over and over. Frankly, if I was doing contract dev, I'd state it as an upfront policy and move to quickly fire any customers that didn't buy in.
By this I mean we forget we have other things - we don't accurately account for meetings and side-tasks. We underestimate the complexity of even simple tasks. We don't account for the flames we fight habitually without much consideration. We don't even recognise the amount of time we spend just relaying and receiving information. Those intriguing and important (and still work related just not explicitly about the task we have estimated) slack messages and water cooler moments aren't accounted for in our estimates.
Most estimates are inherently given on a "if I am in a perfect working environment with no interruptions" basis and we don't even acknowledge _that_.
This is all before we even begin to appreciate that even perfect world estimates are hard because, as Ron Jeffries said:
Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you.I had the experience of working at a company that had the practice of rigorously tracking engineer-hours. Through a time-card system. (this was for billing our clients). This way we always had a paper trail of how long we spent on a given task or project, and it was generally "against the rules" to bill hours you weren't directly working on that project.
This led to having an awareness of that imperfect working environment, and was a powerful enabler of making good estimates.
On the other hand: that documentation effort wasn't free either.
Open source projects are rife with developers demanding the near-impossible from contributors/maintainers, etc. (but plenty of examples people not being dicks as well)
Additionally, they can often be worse (toxic) about it precisely because they are developers themselves, and so think they have that understanding and start acting the alpha.
https://en.m.wikipedia.org/wiki/Project_management_triangle
It's probably the first time i have seen estimation described so clearly as a choice between scope or date.
Am still trying to figure out how something like SAFe works with the above, the gut feeling is "not great".
Great, we'll be expecting you to complete that by the end of next week.
This.
I often find myself saying “you can be feature-driven, or you can be date-driven, but not both.”
Then we start breaking it down further if there is interest and for that we need everyone involved like you said. Not always easy but sometimes it works.
Most engineers can actually estimate things fairly well when they take the time to iterate on a PoC and gather all sorts of details. Estimation fails when management has unrealistic expectations, e.g. asking for an estimate immediately after a proposal, or some set of initial documents are written.
I worked for a company that produced reports for insurance adjusters. Sometimes the reports were small enough to take an hour, and some large enough to take a week to produce.
For some reason the company was obsessed with the "month-end" cycle- people on the last day of the month would work overtime until midnight and occasionally skip usual quality control checks to get things out the door. (And then take the next day off or come in at noon or whatever.)
For reasons I will never understand, with three days left in the month a certain director would spend the whole day running around with a spreadsheet of all the reports that were open and ask people for a red/yellow/green estimate of whether they would be done. The next day and the next he'd repeat the process to get his most accurate estimate of the monthly revenue.
Then two days later, the controller would just hand him the actual revenue numbers for the month ended.
The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe a similar bridge under similar conditions would take similar amount of time). This is not what most places do (and most places don’t spend a lot of time after the fact really seeing how long each phase and part of the process took).
I’d argue that estimates should be removed from day-to0-day engineers and placed with program managers or others whose job is to see how long work has taken and make schedules and estimates off of previous known work.
The other way to get more accurate estimates is to build in systems and processes that require less and less custom work over time. So many software shops and tech companies never invest in this and every new major feature or project is heavily custom work.
Part of your argument rests on reducing novelty. However, that's already covered by the myriad of manufacturing process improvement books. Programming is unique because every project is novel. Any migration, any integration, is going to be heavily dependent on company culture and environment.
Like it or not, estimates are necessary to weight A against B, to scope, to plan marketing releases, to compete, to sell, to budget, etc. You may not get value from it as a coder, but that doesn't mean that there is no value in it.
This does not mean that you need a big design up front, but it does mean that you need to be happy with a level of precision to the estimates commensurate with the funding that has been given to the design process.
Without a detailed plan a lot of space is wasted and the apartment ends up less nice and you often end up reconstructing stuff (if it is small and non standard).
The process takes 10-15% of the total cost of the project. Do people want to spend that? No.
We analyzed our five+ year history of estimates vs actual time, and our standard deviation was larger than our mean. It was ridiculous how wrong our estimates were. The problem was in what was being estimated - coding time. Developers would get asked how long a task would take, and only think about the time spent sitting in front of a computer, typing code, and not the other time - waiting for other resources or people to finish tasks that you depend on, sick days, software and hardware issues, etc.
The only way to accurately take those unforeseen factors into account is by analyzing previously completed tasks that have similar scope. Even then you can only get close.
A couple people have mentioned weather forecasting as a similar endeavor - but meteorologists don't just guess, they analyze previous data.
Estimation that isn't based on concrete data is a fool's game.
There's all this (important) "guff" that people in the development often don't think about and don't care about that you absolutely have to take into account if you want to get even close to a sensible ship date. Some examples: updating license agreements; creating new records or updating them in your licensing system; providing various kinds of information and training to sales and marketing and coordinating with them on launch plan and materials; ensuring your support team is trained on the new product or version; budgeting time for support tasks on existing products; running your early access program, including gathering feedback and implementing changes based on it; and on and on.
The other thing I'd do is front-load all the riskiest work: that way if something goes wrong or is more complex than expected you know early, can communicate early, and there are no nasty surprises late on that might have a negative impact on other parts of the business or customers. You also have plenty of time to come up with contingencies to rescue the situation if it is somewhat time critical.
Even then I'd offer up a "hurricane model", where I'd have an earliest ship date, latest ship date, and most likely ship date, and that window would gradually narrow as the project progressed, the same way certainty about a hurricane's near term track increases as time goes on. Obviously that might not hold true if there's a significant shift in requirements. With our projects what it meant was that by the time we were at the point where we needed to start coordinating across teams around launch activities (generally about three quarters of the way through), there was enough certainty to actually pick a release date that everyone else in the business could work to.
And what did I base all this on? Well, past experience: actual data, even if it was fuzzy or there were too few points for any kind of statistical significance. They key point is that all the work required to ship the product, whether inside or outside of our team, was included in the plan.
Estimates and (increasing) certainty are often quite important to other areas of the business so I would say you can't ignore them, certainly not if you want your voice(s) to be taken seriously in the wider business.
This is important.
I'm in the middle of a dev cycle where I'm doing the riskiest work, and other people depend on it.
Unfortunately, I think I allowed myself to get pulled into the design process too much, when I should have been prototyping like months before I started doing so in actuality.
I allowed myself to get blocked by a bunch of design decisions I could have easily adapted my implementation to conform with, and in turn blocked a few people downstream of my (risky) work.
I'm lucky that what I did is pretty "flashy," because I think management is just happy to have anything at all for the feature I was working on.
The others, not really.
Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate)
Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work.
https://kanbanize.com/kanban-resources/kanban-analytics/mont...
I find this approach a lot less time consuming, more predicable and reliable.
Breaking down work into similarly sized tickets/units can,
over time, be used to predict delivery/capacity
Re: that article - I can't imagine many things LESS accurate than "we have 104 tasks on the board and each team member's cycle time is 2 days so we can finish all the tasks with 10 people working for 20.8 days". Yeah, it makes for a nice graph - but it omits important details like dependencies...
Yeah, agreed. What I've always seen is "break up work into logical units, ideally as small as possible" which always ends up with a mixture of tickets of different sizes.
Teams above a certain maturity level do often settle on a certain number of delivered tickets per month, and when you're looking at that sort of resolution, dependency problems and other factors like those you mention are represented in the data. It's not so much a measure of how productive the team is, it's a measure of how much work the team can get done embedded in the organisation they're in, which covers off their ability to resolve blockers and communicate with other teams.
There's a very different cognitive framing if you count tickets, too: you're not saying to the team "come up with a number, you're going to get shouted at if it's wrong, and you've only got 10% of the relevant information to hand", you're saying "do your usual design process, and we'll use the output to make a projection based on the history." Functionally it might be equivalent to "can estimate accurately" but it doesn't work like that when you're the one in the hot-seat.
In the end, regardless of whatever scoring strategy you use it should always be team centric, rather than individual.
It is possible to say, over the past 6 months, and X tickets, our team has had a Median/Avg cycle of around 2days. If team breaks future work in similar sized chunks, it can very fairly confidently predict how long they will take to do X more tickets, assuming similar conditions.
The added benefit of using small chunks of time, is that one does not need to be super accurate (in most scenarios), it can be 1 or 4 days, all it matters is it's possible to give window of estimation (based on actual data, not guesses) with a certain degree of confidence. (which will naturally become even more consistent over time)
As I've pointed out before, film scheduling is an established discipline. Making a movie is much more complex than a software project. There are a lot of moving parts. Things get changed. There are people problems, weather problems, and transportation problems. Most importantly, if a film project goes into crunch mode, everybody starts getting paid overtime. This reduces the tendency to underestimate.
There are also third party estimates. Hollywood has something called "completion bonds". A completion bond is an insurance policy for the investors. Either they get a showable movie into theaters, or the completion bond company has to pay the investors. A completion bond costs about 5% of the cost of the film.
Completion bond companies do their own estimates. Estimation inputs are "script, budget, shooting schedule, (and) résumés of key crew." To survive, they need a net error near zero - they must overestimate and underestimate about equally. Consistent underestimation would put them out of business.
Since they do a lot of this, they have scripts and financial data from previous movies. They can look up "car chase, metropolitan area, 2 minutes screen time" for how much that cost the last 50 times someone did it. They also have director info, like "director X averages 2.5 takes per scene". All this info is collected across multiple film companies.
The completion bond company has the right to intervene if the project starts to go over budget. Worst case, they can fire the director and take over the production. This is rare, but it happens. "Malcolm X" by Spike Lee (1992) and "Bad Girls" are examples. "Malcolm X" was an epic movie, a bit too epic - it runs 3 hours and 22 minutes - and somebody had to say no to Spike Lee. "Bad Girls" (1994) was just a botched production, and the bond company put in their own director to try to salvage something. It still lost money, but did reach theaters.
That a completion bond company can fire the director puts teeth in this system.
Software design and development is more like writing the books that the script was based on.
Think Song of Ice and Fire, but 100,000 pages long and written simultaneously by a hundred authors.
Seems like there's a hint of survivorship bias. The author will eventually give a bad estimate. There's no secret or trick otherwise it would be widely known by now.
Even the video games industry has been coming around on this in the last decade. This is a sector of the software industry famous for making aggressive, impossible deadlines for itself. It has ruined countless lives trying to hold to them. The smart ones talk about milestones and road maps. They don't announce release dates until they're basically done and ready to cut the release.
This is the conclusion you come to after you churn staff year after year and people leave in droves and never come back.
An aggressive sales team can ruin a small company. If what they sell is a deadline and promises they can't keep your team has no control or autonomy. People feel good when they have autonomy over their work and feel in control. They get burned out when their company/career is on the line when an estimate they were forced to make blows past due to forces outside their control.
I always recommend selling on what you can control. Promise only what you can deliver: your skills, experience, and knowledge. You can try to estimate how long it will take you but you will be wrong 66% of the time. The people in those studies were also as smart, or smarter, than you. There is no secret.
Someone (sales team, developer or anyone else) wants to radically change the scope half way through? They have to cut the scope or adjust the schedule to compensate. Software is infinitely malleable so it's tempting to just accept any change that comes along, but with unmanaged changes and complexity come missed schedules and blown deadlines - it's all very predictable and avoidable and usually caused by a dysfunctional organisation without proper communication or accountability.
This is not rocket science and while there are no secrets or perfect estimates there are certainly ways to break down most work until estimation is trivial. Sure there are exceptions (research, v. difficult new problems) but for the majority of business/consumer software I've encountered, a proper schedule is possible and software can be delivered on time and on budget, as long as the scope is properly controlled, the work is properly subdivided early on and someone is managing the entire process and keeping communication open with stakeholders so that when things change/go wrong the appropriate action is taken and everyone is aware of why.
The Taylorist principles of management don't apply to knowledge work in my experience. Refine your requirements gathering and estimation processes all you want. Your estimates will still be wrong most of the time. They're educated guesses and we don't have the foundation to make accurate ones.
One thing I think you nail though is that communication is key. A lot of good comes from being honest, transparent, forthcoming, and supportive.
I never recommend software teams and companies make estimates. I say break down tasks, make mile stones, set learning goals, and get to work. Communicate progress frequently and keep feedback coming back to the team. Working software talks. When you can see the goal in sight that's the time to start talking about release dates. Once you have that first couple of releases you then you can start developing a cadence. It's all based on evidence and what you know and making promises you can keep.
The simple principles above do apply in my experience, presumably there is some difference in practice.
Maybe everyone thinks they have it figured out but some people demonstrably do, because they deliver software on time which meets requirements. I agree with delivering software early and often, and that is a solid basis for delivering reliable estimates and promises you can keep.
Where estimates fail IME it's down to lack of accountability and communication among stakeholders, which leads to constantly shifting and unclear priorities and requirements.
Once other dependencies are scheduled around a estimate, missing that deadline incurs rescheduling costs so no one wants to see it missed.
Then when it turns out estimates are out, I'm stuck in another meeting where they melt down about how they're going to explain overruns to their bosses. Utterly predictable madness.
Then they had the nerve to get arsey when we started refusing to estimate.
Then there's the "let's split it up into pieces first". This is where, instead of rolling one 100-sided die, we flip 100 coins to get a better estimate.
But my absolute favorite is when the Project Manager asks for an estimate and you give a number and if they think it's too high or too low, they will keep asking until you give them the number they were looking for in the first place. Why even ask? Because now it's your fault if it's wrong!
(side note: There are solutions to these things and they are definitely not the right way to do things and are signs of a toxic environment - but there is hope!)
As TFA says, you do get better conversations with the rest of the business if you refuse to give an estimate.
I tend to operate on the opposite principle, to the point that I believe it is worth doing substantial amounts of seemingly redundant or throw-away[1] work to turn hard dependencies into soft dependencies. But you have to have both a business organization and a software architecture that can support this.
[1]: Really, "throw-away" just means "temporary", and all our work is temporary—the question is just how temporary.
I just found another competitive advantage in my startups.
If you can't avoid giving estimation, try to pad it as much as possible, add every single uncertainty to the task list, and estimate very conservative. Add enough time for testing, communication, work on change requests.
And even after the original estimate is approved / published be sure to communicate updates to the estimation after every single change request, question, bug, new insight.
And if something by chance take less time than estimated, make sure not to decrease estimation, but to use it as a buffer.
If I can assume you’re an SDE for a moment, I actually agree with the part of you not providing estimates. Recently I’ve done the initial estimate for projects exclusively between SDM and PMT with no engineers involved. It has been a lot more reliable and it seems that SDEs are very happy to be absolved of this responsibility. This does require SDMs and PMTs with a good amount of experience.
Not a mature engineering discipline.
If you can budget a planning phase in development that allows you to quickly explore the unknown unknowns and known unknowns to investigate critical bottlenecks and uncertainty before estimating and you're able to lock that down with a set of features, then I think you can create decent estimates.
That's rarely how any development environment in current existence operates though, at least from my anecdata. Most are 'agile' that can drastically shift directions, feature/scope creep is a continuous problem, there's a constant time pressure exerted by managenent on developmeny teams in hope to optimize a bit more productivity out of their high price tags which gives no slack space for them to dig into these issues (except maybe some personal time).
The entire modern development culture in most business environments is designed in a way that makes any sort of good quality estimation nearly impossible. In the best of conditions it can be hard but manageable, most environments are the worst of conditions.
How many projects in mature engineering disciplines are accurately estimated? I get the sense that this is a general problem, even outside of software.
The concept of standardized parts and assembly lines is less than a century old. How accurate do you think their estimates were before they figured out the basic principles of repeatability?
The "mature" engineering disciplines literally just punted on the problem for several centuries, only giving birth to systems engineering [1] in the mid 20th century because they were so bad at it and everyone's back was against the wall in WWII. Before it became its own recognized field, project management in engineering was worse than it is in software now.
Not coincidentally Bell Labs - the company that basically kick started the computing industry - was also the biggest player in the formalization of systems engineering. Since then its been adapted as the methodology for managing engineering projects by everyone from civil engineers to NASA [2]. Any estimate you see for a nontrivial project from the past half century isn't the result of mechanical, civil, or electrical engineers but the product of systems engineers.
[1] https://en.wikipedia.org/wiki/Systems_engineering
[2] https://www.nasa.gov/connect/ebooks/nasa-systems-engineering...
There are lots of reasons for that, which can fall outside of the scope of engineering, but the same is true for software.
One of the things I dislike when I hear this is that it says nothing about the difficulty or cost of getting the estimates. Yes, good estimates are extremely valuable, but solving the halting problem would also be very valuable. That doesn't mean it's going to happen.
A big issue is that to get good estimates, often we need to solve most of the hard parts of the problem. How do we account for the time needed to get the estimates?
> If we don’t estimate then we are saying that software engineering is not an engineering discipline.
I'm not sure I believe this. There are plenty of non-software engineering projects that are late and go over budget. It wouldn't surprise me if that was the norm. Certainly with construction projects it happens all the time.
I'm actually curious about which engineering disciplines actually come up with good estimates. When developing a new type of airplane, or a new engine, are estimates typically accurate? It seems unlikely to me.
The halting problem is mostly a non-problem in settings that really need a proof. We have non-turing-complete languages that let us produce programs that provably halt.
That they are not mainstream tends to show that we don't really need that proof very often actually.
My favorite moments from events like WWDC are when you are introduced to some really cool feature or app for the first time, and then the speaker goes "available today". The fans love it, the news sites love it, whenever you can immediately try out something the hype for that product goes up 10x.
When you only show the product when it's finished, you no longer need to estimate anything.
> dependent activities
This is where I think the real problem is. If you have a feature that no one else depends on, if you have a story that nothing else depends on, don't estimate it. It doesn't matter. That is a nice to have. It'll arrive in some sprint eventually.
If you have a feature that other things depend on, before estimating it, you should ask if it is possible to create that feature without any dependencies. Could the other team that you are working with code such that they work with your current product, and when they update and you update, the new feature turns on? Can you do the same for their product? Great, we don't need to depend on each-others updates.
If we had a mature engineering system, I don't think we would ever have any dependencies.
Perhaps you aren't perfect, and there is no way to rid the dependency. Go ahead, estimate it. Then double that estimation. Then convert that estimation into one larger unit. 1 day becomes 2 weeks. 2 weeks becomes 4 months. There, now you can build schedules around it.
If the team provides an estimate that falls one month after the deadline, the pressure for them to change their estimate will be extreme as well. In reality, if management has already decided when the product should be released, they don't give a fuck about an estimate. What they're interested in is for the team to take ownership of a decision they didn't make, and that's what the estimate is for.
A good estimate may also require "spiked" to test concepts to get to a reasonable estimate.
I'm currently in a project that is terrible as the development team provides estimates without even reviewing the requirements and now "18 months late" with many pissed off stakeholders. It is a caustic situation. People are quitting the company due to the politics, frustration, and pressure due to this.
I imagine the OP meant "spikes" and either accidentally hit the 'd' instead of the 's' or simply fell victim to autocorrupt.
You'd make a great developer with the perception of the error cause before confirmation ;)
A great product manager is as priceless as a great developer.
...
Except weather reports 3 months out are not reliable, unless they are so vague as to be meaningless. I have frequently encountered people who claim to be able to give accurate software estimates. Inevitably, this means that they simply know how to cut requirements as the promised ship date arrives. Which is a useful skill, but not the same as accurate estimates. I have stopped arguing the point, because it doesn't matter what the reality is, business concerns mean that an estimate is required sometimes. But it doesn't mean anything more than the weather estimate for 3 months from now. If you got it right, you were mostly lucky.
"Cold" is not an adequate analogy for the sorts of estimates that non-delivery parts of businesses seem to think they are entitled to, and it's not reasonable to say people can't be taken seriously for rejecting that trap.
Some may claim they have personally experienced rain, so your model must have some faults, but just ignore those plebeians.
I think this is one of the things that Shape Up got the most absolutely correct - inverting the relationship between an estimate and time.
We've been asking the wrong question all along: Instead of asking "how long will X take?" you should be asking "How long do I want to spend on X?". It changes the entire dynamic of the situation to one that allows management to see the trade-offs in a given set of work, and lets the engineers tune scope to match expectations.
Any approach that still asks "How long will X take?" is dead in the water.
Granted, this whole thing works for me as I happen to thrive under pressure.
I actually would say I do too, but I also appreciate deadlines for the time compression effect that they instill that you can't get from anything else.
> I find putting an estimate together makes me think through the design
I agree, and I'm not advocating for ignoring all of those details for a ticket or project. I'm just saying that the important thing is to flip the conversation. All of those things should be known regardless of the time question.
For stories that have significant unknowns you'll still be wrong though.
However, even then it's still worthwhile providing estimates. The benefit comes from knowing how wrong you are. If you look at a story and have a guy feeling that it's quite simple but it actually takes far longer than the estimate that's useful data. It tells you that there's some aspect of the story that you weren't expecting, which can point to understanding where unknowns lie, or it means you thought the code was simpler than it really is so maybe there's some technical debt to be refactored, or it means that you failed to fully understand the implications of how far-reaching the story was so you should have done more upfront research. All those things can inform the next estimates you provide.
We have our product owner in the estimation session (we use planning poker), we discuss requirements, assumptions, sometimes even a potential approach or two to building a solution. That process frequently leads to discovering unknown unknowns, new requirements, and sometimes even reevaluating whether we need the change.
Estimation discussions involving a big chunk of the team can be truly useful.
In my experience, software project estimation is the thing that everyone thinks someone else must be able to do well, and that they could do it if only they had more discipline. Then we get the tired old advice about breaking the project up into smaller chunks. But all the studies I've read of actual estimation methodologies show something like 300-600% error rate.
People think this must be doable because they want it to work, and they want an estimate. It's the same way that people thought one witch doctor was better at curing disease than another, when in reality none of it really does what's claimed.
I'm convinced that elaborating the spec in enough detail is the work of software engineering, and once you've done that fully you've done the whole project.
For some, an accurate estimate would mean that 50% of the time you're over and 50% of the time you're under. But management too often takes this type of 50/50 estimate and then makes all kinds of promises and contracts based on it. If you want an estimate that we're going to hit 99% of the time, that is going to be much much higher. Many places I've worked management would balk at any discussion of percentages like this when making estimates.
As the saying goes: What you say is "there's a 50% chance we'll be done in 6 months, if there's no distractions". What they hear is "I promise we'll be done in 6 months".
- They don't actually need to estimate, because the task can very obviously be completed by the previously window
- They're simply trying to prioritize two different features, so the estimate doesn't need to account for who will be working on the project, known vacations, meetings, etc.
- The business is trying to use the estimate for strategic planning, so high-confidence, or multiple estimates (optimistic/normal/conservative) are actually needed.
It's similar to when someone comes to engineering and asks "Please build this button for me" - it's always crucial to ask "Why?" and understand the problem they're trying to solve, since often what they've asked for is not what they need.
Why do we as an industry put up with this? Lawyers Don't, Doctors Don't. Pretty much any Degree based industry doesn't. If it goes over budget/time they all just shrug and say that's how it is if you want it you have to pay more. Yet Devs are somehow supposed to know to a dollar how much the unknown will cost?
And both deliver abysmal cost-benefit and have obfuscated competence to the point that it is nearly impossible to discern good ones from bad ones, as long as the bad ones meet the minimum standards of the license. In fact, both doctors and lawyers have fought hard to prevent any sort of evidence of their relative competence and performance from being accessible to their customers.
> Pretty much any Degree based industry doesn't.
Only non-degreed people should be accountable?
> Yet Devs are somehow supposed to know to a dollar how much the unknown will cost?
"To a dollar"? Straw man.
It's a class difference. Fussell places the typical doctor or lawyer in the Upper Middle. Most developers are, in their relationships with their employers and their employment (not in terms of income!), Mid-Prole, High-Prole, or solidly Middle, under a Fussellian classification. Elevating us to Upper-Middle would put us on par with much of upper management, and where most middle managers want to be but are not and are constantly irritated that they are not, in terms of freedom and respect.
No surprise that corporations (managers, in particular) resist this inversion of class-liberty compared with the corporate hierarchy, especially since they (managers) set the rules and the tone. It's bad enough we might make more money than they do. And besides, most developers haven't been socialized, in childhood, in school, or in their early career (so, the periods of life when class education occurs) into the Upper-Middle. We don't really expect better, would probably feel uncomfortable or like beggars requesting better, and (truly) may even feel uncomfortable or lost with the resulting freedom.
Put another way: who do doctors in a hospital answer to? Who do lawyers answer to, in a law firm? Classically, doctors and lawyers, right? Notice how upset doctors are about professional management infiltrating hospitals? That's them resisting dropping down in social class.
The bottom line is this: exact estimates, especially for large projects are a crapshoot. There is often more than one way to solve a business problem, and long-lived consequences for maintenance, operations and future development. The best solution to large problems can not be arrived at by simply throwing an ill-conceived one-liner prescribed solution over the wall to an engineering team and say "estimate this". What works is to bring a small group of highly skilled practitioners and business operators who have the capability and experience to zoom in and out of the problem space enough to shape a sane low-fidelity plan, and then commission the right discovery and validation to formulate a full plan. This does depend on having the right people in the room and mutual trust between them. It's very easy for one bad apple to derail this whole thing either through outright incompetence or else inability to listen and understand another point of view. Often on HN we paint the picture of the clueless pointy-haired boss making bad decisions, but equally as damaging is the arrogant engineer who is unable to see past their own biases to play out potential tradeoffs with other areas that they don't have deep expertise in.
A thoughtful estimate shows care in understanding the project and how it fits into the greater whole of the existing platform. It allows all members of the company to trust in the timelines of the engineering team and align their work to meet the milestones.
An estimate is by no means certain. The size of a project and its novelty will affect the certainty of the estimate. However, not doing one is careless
the fundamental problem is that management does not want estimates. they want quick estimates (ie close to zero effort) and after that they turn around and use those estimates as deadlines.
now as a developer what are you supposed to do? you’re gonna get burned a couple of times and be forced in death marches. after that you’ll: take your time estimating. you will pad your estimates to mitigate risk. ruthlessly dissolve complains about how big the estimates are by pointing out all the things that you need to think about and do. reestimate everything when anything but the most trivial thing changes.
everyone loses. really. management believes that they are squeezing the maximum amount of value but they’re not even close. developers end up doing the bare minimum and will take absolutely zero risks even if it would make the product better. fuck all that agility we claim to have.
welcome to software development in the 21st century. oh… I know. I’ll use copilot to write my code and I’ll also update it to estimate stuff! glorious!!!
If you don't schedule time to estimate, the estimates are worthless. Rule of thumb, anything that can be done by one engineer in less than 1 month should take about 1 day to estimate, anything under 3 months, one week, anything longer should take up to a sprint (2 weeks). As a manager with experience, you should roughly know what level of time needs to be spent by your team planning their work prior to executing. Chances are, in the estimation work, the engineer(s) will discover questions that have not been answered by the product specification that need clarification. And that's the whole point: getting as clear of a picture as possible.
As for any manager that thinks they can squeeze value is naive about what software engineering is. This is not a manufacturing line.
There needs to be enough time in the schedule to design to an adequate level for the problem at hand. You don't necessarily want as clear a picture as possible, but you do want as clear a picture as necessary.
Marketing has a goal of 5000 new customers. They do not estimate it by conversion history, outreach, customer preferences and other values in their model. But they could call it "estimate" with some thinking. But then they'd have the same problems of being "bad estimators" as developers are.
We in technology call our goals "estimations", and if we're "wrong" we are nailed for it. They are tied to our professional skill in a way goals never are.
Let's call our estimates goals as everyone else does.
Also: Many people confuse estimations and measurements. It's easy to sum 5 throws with a dice. I can do that hundreds of times correctly. It's impossible to predict the sum of 5 throws before the dice is thrown correctly all the time (only on average).
If Google, Microsoft, Apple, Blizzard, etc can't produce accurate estimates despite employing 'the best of the best', wouldn't that imply it's a nearly impossible task? I can see getting order-of-magnitude estimates, but nothing more accurate than that.
You have to try, even if you know it's going to be bad/inaccurate.
Estimates do matter - but blindly doing the same type of estimate for all tasks is missing the point. (Which is why I feel story pointing is overdone.)
I shave the scope as much as possible and make sure to report on my progress daily - usually by demoing.
This is actually something that was originally suggested by my manager in one of my former projects.
With the scope devoid of non-critical pieces and daily updates it's easier to monitor the progress and notice any roadblocks early on.
Normally you'd do something like this during standups, but there's a world of a difference between saying what you did and presenting it.
Generally people are more interested in whether something will be delivered on time than how long the specific pieces will take to finish.
Also in this system any accusations of villainy on part of those you report to never get a chance to happen.
I don't much like front-end work, but seeing how easy it is for front-end devs, designers, and UX folks to get noticed, makes me seriously reconsider my priorities, sometimes. For them, it's practically effortless, just something that happens.
(UI/UX can generalize about the other side, too ;D)
Ugly but technically-impressive weekend code projects may impress programmers and gain visibility there. Meanwhile, designs routinely impress non-technical management, stakeholders, product managers, and clients. I mean, the degree to which that's true is so well-known that it's practically a cliché. There's a huge difference in how hard it is to get people who matter (in terms of career advancement, comp, and even just staying off your back about how much work you're doing) to notice your work. It's not at all comparable, and it's entirely to do with how legible one's work is to the rest of an organization.
The down side is that where non-UI developers meet confusion and ignorance ("so... what is it you still need to do? Why will it take so long? What do you mean it doesn't work yet? Oh you made the query finish in 3% the time it took before? That's nice, thanks. Moving on...") designers instead get endless suggestions, because every dumb-ass thinks their ideas about UI are good, and some of those dumb-asses really, really want to influence the design (why? Because it's so high-visibility, so it's something they can point to for higher-ups or in a portfolio and say "I did that"—they want to acquire some of that natural designer/UI/UX legibility-of-work for themselves)
It's by Steve McConnell (also author of Code Complete) and largely covers what this author does (but more, and in more detail). I have found it consistently one of the more useful books in my library - particularly for its emphasis on error bounds and on how bad people are at estimating confidence intervals...
Steel in tension, low uncertainty, LRFD safety factor is 1.75. Steel in compression, medium uncertainty, safety factor is 2.5. Anything to do with soil, high uncertainty, safety factor of 4.
Same principal really. If it works for life/death scenarios, it'll work for you!
https://jacobian.org/series/estimation/
For example, here's an except from the SWAG article:
> The tradeoff is time: estimation techniques, including mine, require some time to produce any level of accuracy.
> Sometimes, though, it’s less important that an estimate be accurate than that it be quick.
Even if we were to try considering interactions we would fail. Like the weather, and other topics in the complex systems domain, software is sensitive to initial conditions. A small change in input (change in data or code) creates a large change in output.
We generally accept the upper bound on weather forecast to be 7 days and even then we might bring an umbrella just in case. Forecasting software many months into the future is futile - if taken at face value. Used as a general guideline it is usually ok.
A paradigm shift is needed. Both inside and outside the industry. Software is not industrial construction, hence the same logic (project management) do not apply.
Software is creation, conduction and orchestration. Not production or manufacturing. We are not teams of architect, builders and operators. We are musicians in a orchestra.
How long does it take to write a symphony?
this is especially true if you consider the incremental work projects take on. THAT incremental work IS forecast-able. problem is often all the information need to be able to make that forecast is not in one place & the discovery process is often left unaccounted accidentally or on purpose to commit to tighter deadlines. add to that changing requirements and you have the state of software estimation we are in.
Let's agree that estimation is possible to a certain degree. We know this and accept the inherent uncertainty.
Modern project management is whole sale copied from industrial construction and manufacturing. It seems no one stopped to ask whether the same logic applies to software creation. And it doesn't.
The business side of IT is stuck in a mental model build on construction and manufacturing. Yet the process of creating software contains neither of those concepts with the exception of automated build and deploy (and costs for those are negligible).
It is also interesting that no distinct vocabulary for software exists. We build, deploy, construct, have factories and so forth. Again copied from disciplines which are complicated - but not complex.
It is not possible to obtain the information you refer to by analysis. That's a property of a complex system. Analysis of parts neglects the interaction between parts and in software more or less everything is connected.
This is one of the reasons why we cannot forecast weather and why we cannot reliably estimate software.
Now, if I start my explanation this way I'm also sure to lose their attention. So what do we do? Which intellectual approach will captivate these people, retain their attention and at least plant a seed of doubt in the established way of working?
In some scenarios you need projects and full-on estimates though, ie. for planning of hard deadlines. But the reason you want to avoid it has to do with the discovery process during development. Everyone conventiently "forgets" this while focusing on their own ends (local optimization).
Quick feedback-loop with A/B tests are maybe easiest way to achieve understanding on how AM recommends people develop together. Such setups may end up costing alot though, unless truly done in the spirit of AM and recognizing the costs of shortcuts.
If necessary I prefer to get very clear what is needed to [make that sale/give that demo/whatever they need] and give a very conservative range with a bunch of caveats. The more flexible the requirements and timeline the better. It means with a bit of luck you can deliver early and/or throw in some bonus stuff at the end.
If you are inevitably going to miss a deadline, discuss it as early as possible and discuss how to proceed, where to focus etc. You can often reduce the scope, cut more corners, move the deadline, find more resources, or do damage control. Whatever is necessary.
That's why I don't think (accurate) estimates matter too much, it's more about communication, managing expectations, and being flexible enough to adapt along the way.
The guy basically listed excuses for padding the estimate.
Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].
This one is really the big one:
"9. Both estimation and control are needed to achieve predictability. "
In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.
Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.
I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]
It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.
But that won't work, beyond a fairly humble scope.
[0] https://www.amazon.com/Software-Estimation-Demystifying-Deve...
[1] https://stevemcconnell.com/17-theses-software-estimation/
[2] https://littlegreenviper.com/miscellany/the-road-most-travel...
The more uncertainty in the path, the less accuracy in the estimate. Kahnemann's latest book "Noise" provides some good background on why this happens.
Having multiple people do independent estimates and averaging them probably gives better results, and having a clear process to document assumptions and test sensitivity to those estimates can also help.
After 30 years in this profession, I've lost hope that we'll ever get away from the mindset that developing software is a mindless, mechanical, repetitive task rather than a creative endeavor.
Software is trivially copy-able, and as such large software projects are unique enough that accurately estimating them is impossible. This is in contrast to something like building a house. I build a single house, figure out how much that cost and now have a very good reference point for how much building that same house over and over will be.
I really like the approach that Basecamp recommend in Shape Up[1] where the team pivots to reasoning about work in terms of appetitie rather than expected time.
[1] https://basecamp.com/shapeup/1.2-chapter-03#setting-the-appe...
I wrote more on the problems with estimations, and some solutions, here: https://camhashemi.com/posts/accurate-estimations/
I don't have any beef with it being hard. I have a major beef with it setting invalid expectations, having no basis in calculated fact, and overall being useless/time consuming to the people having to meet these deadlines and participate in said "agile" rituals.
I'm all about capacity. If we can understand what a team is capable of or the capacity of said team, we don't have to guess how much work they agree or don't agree to do or force them to use a crystal ball at the weekly séance.
Time estimates are always wrong, it always slips to the right. This is always used against you. You suffer because of it. Your work suffers because of this.
I get a couple extra hours a week by not doing daily standups, retrospectives, sprint planning, etc etc. This allows tasks to be shipped faster.
If there's a problem I communicate it up and stakeholders understand.
Want to know how long it might take? Look at some historical tasks in Jira and compare timestamps.
I get why stakeholders want estimates, don't get me wrong. But I can't help but think just letting them go and trusting the team is ultimately more effective in many cases.
Don’t get me wrong, sometimes distrust or limited trust is justified, but it’s not an ideal.
This results in punishment for poor communication. The punishment starts when they claim they can't provide anything that approaches estimate, or attempt to weasel out of a discussion. It should be clear to the customer when and how you are delivering commitments. Poor communication turns an estimation discussion into one where a developer has overcommitted.
Even if you can assign zero time estimates to tasks, or even zero estimates for how long time estimating task will take, you can provide a view on how you'd go about it and the relative priorities for your investigation. This is a critical part of building trust which is necessary for the long-term success of any project. Communicating a clear perspective that does not make commitments is important for building the relationship which will give you wiggle room late on when you have to make adjustments.
When a commitment is made to the customer, any associated estimate needs to be provided along with context. Providing a confidence number leads to misinterpretation because different tasks may require different analyses. It is better to encode it in some other way to highlight things like: multiple interviews conducted, whether a coding spike was done in the area, whether support contracts are in place for the 3rd party service required, etc.
As the project progresses, there should be some kind of update to those commitments. This is where again it gets scary for people because they don't like having these candid discussions.
In all of this, I don't prescribe any methodology. This can fit with any methodology, but you have to find a way to fit it in. Waterfall has lots of clear points where commitments are made, but it doesn't have the feedback mechanism in its purest form. Updating commitments is essentially part of "agile", but the recording and communication can sometimes be a challenge. The job of the developer is do enough of the right work to set the right commitments and communicate around them.
A developer trying to communicate a clear perspective that does not make commitments will be seen as attempting to weasel out of a discussion in such an organization.
Customers understand 95% confidence better than they understand coding spikes in my experience.
https://github.com/SixArm/sixarm_project_management_rope_est...
With ROPE, the four numbers combine together to create a larger and stronger estimate. I do estimates for clients, and ROPE provides a way for each stakeholder to see that estimates are really ranges of probabilities.
What, if anything, I say about these estimates to anyone else depends on the culture of the environment, but the experience of estimating has made me better at explaining why it is going to take longer than you think, when that case needs to be made.
1 Effort versus calendar time.
2 Estimate versus commitment.
3 Confidence level - are we talking P50? P99? P100 under some set of assumptions?
If the organization is spending a million dollars it's reasonable for them to ask for an idea of what they'll get and when!
there's certainly an element of personal pride in that dynamic I think. You're asked to give an estimate. You give it. You now feel like you've staked your professional rep to it.
the author shares his method for coming up with estimates, and it looks like an offline process that involves more than a gut check. I think for sufficiently large features we (eng managers, eng peers) should encourage engineers to _not_ give on the spot estimates given we know how difficult it is to estimate.
Then, often, toss the estimate.
Just keep breaking the problem down into sub units that you or your team understand and can fairly accurately understand the effort and risk of (because they've been done before)
Or when breaking it down will require going to a level of detail that means basically fully designing/writing your system in order to estimate it?
That is what I'm against mostly. If I give you an estimate, you accept it, or don't ask me for one.
Guess what we get it's hard but we have to do it so we can plan release, usage (with Sales) and spit out revenue targets to justify the initial spend.
It's all about confidence of estimates. Many small things are easy to estimate and have high confidence. We're good at that stuff.
Where it gets super difficult are greenfield new products that span across multiple teams,both engineering and business. Without burning your entire budget on the estimation process you just have to have exceptional buy-in from all teams and start working, that's the best way.
Where things get tricky are when one business vertical suddenly has a new urgent #1 priority during the build and has to divert away attention and resource. Everyone can lose momentum so takes some business and engineering craft to hold it together.
All part of the gig.
estimation => "commitment" => "failure" => padding => distrust
and much like Global Thermonuclear War the only winning move is not to play.
Please do! I'd find it really valuable. (Not necessarily OP. I'm happy to hear from others as well.)
https://gioorgi.com/2021/estimation-rules/
And it works :)
^^^^^^ This and other lies told by management. :P
/s
Maybe just ranking tasks by difficulty, or using Fibonacci rankings as recommended by some for Agile story points, would be a better use of everyone's time. That way, you can still say "A is roughly X times harder than B", without trying to rely on (almost certainly wrong) estimates in terms of days/months/years.
It's a scale that you can choose where you want to be.
Yeah, that is why I do it anyway. This is not insightful.
Read "Thinking, Fast and Slow" where he talks about estimating the time to create a new textbook.
"If you think something is hard or not, both ways you are right"
Resource allocation.
I can't tell if there's a really deep misunderstanding of what the author calls "no-estimate" systems, or broad agreement but with a small/superficial difference in preference on an implementation detail.
> However, sooner or later, someone’s going to ask “when will Feature X ship?”
Story points let you do this.
As I see it, the key idea with what the author calls "no-estimate" scoring systems is to psychologically decouple the act of estimating from "real time units" into "abstract work units", which (the claim is) are more accurate than "real time units". Most engineers are bad at producing time estimates for things, but if you ask them for a "points estimate", they are more likely to compare the new task to representative examples of past work (which tends to be more accurate), whereas asking for a "time estimate" they are more likely to envision themselves completing the task at hand (which leads to overly-optimistic estimates).
Given a set of points estimates for upcoming tasks, you look at your team's velocity of "abstract work units" per unit time, and you can project timelines for your backlog. The goal with scrum story points / t-shirt sizes is not to avoid estimating when a feature will ship, it's to make that process more accurate.
Scrum suggests that you try to keep a few sprint's worth of tasks finely-groomed, and keep the rest of the backlog coarsely groomed (i.e. rough estimates at epic-level, where you might have blocks of work that are multiple developer-months in size). This is using the "lean manufacturing" principle; don't spend time grooming/analyzing/estimating work that you're not going to use immediately, as it takes time to do so, and the backlog is subject to changes which would invalidate the preparation you did. But if you have a specific need to forecast 3-6 months of backlog, then of course you would do so, and points-based systems are capable of doing so without any modification.
There's nothing more to it - if you follow this process you end up with a roadmap/backlog that gives predictions for when everything you've estimated is going to land (i.e. "when will feature X ship"), with uncertainty naturally increasing the further in the future that you are looking.
To be clear though -- if you prefer using "days" as your estimate unit, that's completely fine. One of the key principles about doing lower-case-A agile software development is that you need to experiment and figure out what works for your team. I'd recommend that you retrospect on how many "days estimated" of work you actually complete per day though, because it's likely not to be a 1:1. And then, if you're regularly completing 7 "days" of work per 10-day sprint, wouldn't it be more sensible to forecast that you'll complete 7 "days" per sprint, instead of constantly claiming you'll complete 10 days of work every sprint, and only finishing 7 of them? Now you've re-implemented points. Of course, I think the author would prefer to say "fix your estimates and stop saying you'll do 10 when you only do 7", but in my experience the actual amount of work delivered is very lumpy, and so it's hard to close this feedback loop accurately.
A middle-ground here is to distinguish between "burdened" and "unburdened" days, where an unburdened day is the mythical "if I had no other tasks, how long would this take me?" estimate. These are closer to what an average developer will give if you ask them for an estimate. Then you can convert unburdened=>burdened by some ratio, depending on how much time you allocate to non-task time. These are things like devops work, on-call, code review, architecture review, etc. You can improve the unburdened/burdened time ratio, so it can be nice to be able to keep all your old estimates valid as you remove/add burden from your engineering team. In this terminology, the author advocates for asking developers for fully-burdened estimates, i.e. the estimator is responsible for folding in all of the complexity of non-sprint tasks. In my experience, few engineers (very few below staff level) are good at this process, as it's hard, and is fairly orthogonal to most of the normal task work that non-managers participate in.
Now, the case for "the author is making a superficial disagreement" - if you hop over to the author's technique for estimating (https://jacobian.org/2021/may/25/my-estimation-technique/) you'll see a very sensible process that is to my eyes structurally isomorphic to the standard best-practice "agile" techniques, including using time-boxed spikes to reduce implementation uncertainty, and proactively breaking up large tasks into more easily-estimatable chunks. The main differences I see are that the author estimates in fully-burdened days instead of points, and is more explicit about communicating the uncertainty on the estimates given. (In standard points-based approaches you just decline to give an estimate with "high uncertainty", or would give the pessimistic worst-case estimate, and would prefer scheduling a spike before starting to work on something that's highly uncertain. In some cases I can see where an explicit uncertainty range would be more useful to external stakeholders, so I like the author's process. I also can see that asking engineers to be explicit about their uncertainty might be a good way of achieving the same sort of decoupling-from-the-happy-path that story points are aiming to achieve. So overall it seems a good system.)
Maybe sales can sink the company.
Only if you work in an extremely repeatable well trodden domain. If you are so skilled at estimation, I’m sure Tesla would love you to tell them how long FSD will take and would pay a premium!
If you really do think that every project you're working on is completely incomparable to anything you've worked on before you're probably concentrating on too low level details.