[steverb]

Here's my beef with estimates.

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.

[mason55]

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.

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.

[lowercased]

> commit to something, but you don't know what...

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 :)

[Jenk]

We don't even need to pretend it is an outside-of-technical-people problem. Developers (and just people in general) are just as guilty at mis-estimating their own capacity for work.

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.

[Pokepokalypse]

>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_.

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.

[scrose]

Then you have the companies that take every estimate and cut it down to 1 month without changing scope. Doesn’t matter if the estimates are 3 months worth of work or 6. And now as an eng you have to either lowball your own estimates and burn yourself out to seem like a ‘team player’, or push back and burn yourself out from a losing battle.

[mcavoybn]

I don't think the point of lowercased's comment was that devs don't underestimate tasks to the same degree that "outside-of-technical-people" might. They are saying that "outside-of-technical-people" don't have the experience to understand how difficult it is to give an accurate estimate or how much pressure is put on devs to agree to a deadline and take responsibility for making something happen by that date. This is compounded by the fact that stakeholders are unwilling to define or commit to a detailed set of features or acceptance criteria. The bigger the project, the more painful and difficult this becomes. Stakeholders say "Make it faster!!!" then engineers say "We agree!!! any ideas on how?".

[Jenk]

That's fair - my intention was to say that non-engineers aren't any worse than engineers. I've seen the same puzzled look and demands from development teams that are requesting changes from other development teams.

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.

[mason55]

Yeah, it's definitely different if you're working on a contract basis. At least with internal stakeholders, whether you're building product, doing enterprise integrations, or building internal tooling, you just need to make sure that you have exec backup (or you are the exec). If you have buy-in then you can basically just set your team's policy and be done with it.

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.

[whimsicalism]

This is why I prefer to work for people who are smarter than I am, rather than the reverse

[amatecha]

Yeah, it's frustrating to get that push-back when it's like, those clarifying questions are just the tip of the iceberg and are required simply to get started -- basically the whole rest of the project is going to be resolving "nitpicky" details like that until it's done.

[sharken]

It sounds very much like the constraints of the Project management triangle:

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".

[cjk]

> "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."

This.

I often find myself saying “you can be feature-driven, or you can be date-driven, but not both.”

[musicale]

> 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

Great, we'll be expecting you to complete that by the end of next week.

[BjoernKW]

A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome.

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.

[tshaddox]

> However, in the end, code is just a very detailed specification of the design that produces a desired outcome.

Yes, exactly. The code is a technical specification that is so clear that a very dumb uncreative machine can follow it perfectly!

[EricE]

"A common misunderstanding about software creation is that code is the desired result." Here here! If I have my product owner hat on I don't give a flip about the code itself; I'm interested in the business value a properly coded application unlocks.

[mr-wendel]

What a fine cut of beef this was! The very last sentence is what really gets me:

  > It requires buy in and input from the entire business stack.

In my experience, this makes or breaks everything. Unless you have external buy-in and external understanding of all the points steverb enumerated:

  - 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.

Additionally, the point of estimates is planning, and planning really only matters when it aligns priorities for multiple teams... the more alignment needed the more important this becomes.

Everyone has to do the dance or it's just no fun.

[snarf21]

Well said. My current rule based on experience is that estimates should only be hours/days/weeks/months/quarters/years with NO numbers. It is to give a sense of scale and effort so it could be prioritized and/or modified. If they want exact dates, then it is like you said, several days/weeks to go get an accurate date. I only wish that the sales team had to commit to closing dates the same way software teams do.

[mtippett]

That's actually a good hack. I tend to take a similar approach, but using approximate days in a fibonacci sequence.

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.

[snarf21]

Yeah, I always think about my structure as "some small number of h/d/w/m/q/y". I count 1 week the same as 3 weeks in terms of scale. ymmv

[brightball]

I’m a big fan of avoiding numbers in estimations. The moment a number is included, people start adding them together to create metrics that don’t show any useful information.

[cpeterso]

I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ...

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.

[novembermike]

The argument I've heard for T-shirt sizes is that if you go to numbers people try to add them together when that's just not how it works. I do agree that T-shirt sizes don't work that well though.

[cpeterso]

I see what you mean about trying to think abstractly instead of about numbers. But once you have t-shirt sizes for some tasks, what do you do with them? You can't compare them. You can't convert them to date forecasts. You can't use them for sprint capacity planning like you can with story points.

[username90]

> 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.

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.

[detaro]

> Rewrites per definition already has a perfect specification in the old code

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.

[rickbad68]

In other words, a rewrite is never actually that. There should be a better word we use for this, like 'replacement'

[majormajor]

> 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.

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.

[spyspy]

On the flip side, a full rewrite is really the only way to surface and understand all of those edge cases. People seem to harp on the idea that rewrites are bad, but I find them to be a natural part of the SDLC. It's a way to refresh the mental model for the devs currently working on it, since the original dev(s) probably moved on long ago. Updating the tech or architecture itself is just a byproduct.

[majormajor]

That's an interesting take, and getting that context is valuable, but it seems like there really should be a way to do that that's less disruptive and destructive to "actually being able to deliver new features" than a full rewrite that stops the world for months or longer...

[sreque]

As someone who has argued against a rewrite, lost the argument, and then proceeded to do the rewrite, I would push back strongly on the notion that we have a perfect specification, which is just "do what the old thing did". This specification is woefully incomplete, of course, just as a vague requirements document for a brand new service or product is incomplete.

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.

[dalbasal]

I think of it this way. All problems that become sticky problems, got that way by being sticky. Re-writes encounter the sticky problem one way. When the spec is real, the spec is vast. "Do everything GMail does" is a lot of things.

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.

[nicoburns]

Rewrites only really have a perfect specification if the original team does the rewrite. Otherwise there are likely all sorts of behaviours that the rewriting team is not aware of.

[stepbeek]

The business might not know enough for that estimate to be possible either. It reminds me of this quote from Andrew Wiles about mathematics:

"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...

[dalbasal]

He can ... really really accurate estimate, ... a lot of time .. building .. verifying .. actual requirements.. designing ... solution .. validating .... process will require dev resources.. resources... people.. support team.. a lot of time.. very expensive.. scary.. and I'll be nakedly responsible for my own mistakes.. </inside head>

"How about we do it that other way. You mentioned devs could keep throwing stuff against the wall. I like how that sounds."

[regularfry]

The way I express it is that estimation is fundamentally a design process. You can't get an estimate without doing design work, to some appropriate level of detail. That design work is not going to spring forth from the void unbidden, so it needs to be paid for.

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.

[handrous]

IMO the best use of "agile"-style planning is to replace the estimation process with development. After 6-12 weeks you'll have some amount of working (if minimal) software, and a decent (by software planning standards) idea of how long at least the first major set of features will take. If you like what you see so far, and the estimate doesn't seem like it'll wreck your budget or timeline, you keep going. If not, you reconsider things or stop.

...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.

[regularfry]

The unfortunate truth is that as soon as someone in the process wants an estimate, rather than wanting to see delivered value, you've already got a situation in which "agile"-style planning is on the back foot. Aside from any business value there may be in the estimate itself, insisting on being given one is a political move designed to put software delivery organisations on the defensive: the framing is that IT is a cost centre, not a value source. That's so common that it's easy to forget that it's not the only choice.

[waylandsmithers]

My own personal anecdote:

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.

[solveit]

Perhaps an insider trader trying to outpace all the other insider traders?

[pwthornton]

This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do.

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.

[regularfry]

I've seen counting tickets work fairly well. If the team is well-practised at breaking work down into tickets below a certain size, chances are good that the number of tickets completed per month will be fairly stable. That reduces the problem to "can you break this piece of work down into tickets, please", which isn't framed as an estimation problem with any attendant "no, that estimate's too big, try again" pressure. The bonus is that you can tell when a team has a stable enough process for this to work by looking at their ticket history over a few months, and the "estimate" (projection, really) is provided by the team themselves, so you don't get into a toxic situation where a team feels they're being held to an estimate someone else gave on their behalf.

[ppeetteerr]

Depends on what you mean by accuracy. There is no bullseye with estimates. It's a means to set expectations and to show that you've thoughtfully analyzed the 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.

[brightball]

This is 100% accurate and it's the reason that I prefer the SAFe (Scaled Agile) approach to estimation and planning over the common Scrum approaches.

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.

[tomrod]

In practice, devs are still writing code on PI days.

[brightball]

How so?

[tomrod]

With computers and dev tools, trying to get the current PI complete.

[brightball]

If that happens you’re just supposed to include what is still to be done in the next PI while you stop everything for PI planning.

There are too many people involved to just skip it to keep working.

[tomrod]

And yet!

[hyperpallium2]

It's also very useful for personal projects, where you are the entire stack. Strangely, it's still difficult to get that buy in...

[codegeek]

That's why I try to give Ballpark first, not estimates if I can get away with it. I would say "This can cost anywhere from $x to $y units (time/money)" where $y-$x is usually a big range.

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.

[zaidf]

At my last job, I think 15-20% of Engineering Team's time was allocated for estimations (including multiple back and forth to clarify specs with product etc.)

[anthony_barker]

Have done some apartment renovations recently I find the same thing with architecture, architects.

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.

[lxe]

> But the business invariably doesn't want to spend the time and money to do that.

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.

[swaggyBoatswain]

Estimating is hard. I like doing it too but it takes me several days to get an accurate estimate. Takes a decent chunk of meetings, figuring out every task that needs to be done, plus major risks and blockers