Hacker News Reader

Comment by didibus | Hacker News Reader

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote.

The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and headcount you're willing to give, how much tech dept you're willing to take, etc., for the privilege of getting their business.

If you see it for what it really is, you'll see that it works pretty well actually. The business gets more out of you for less to them. It was never about having an accurate timeline or helping with planning or prioritizing, and always about negotiating a better contract with the dev team.

Now keep in mind that the "business" in this case is a person who need to report that through their amazing prowess of administration and management, they personally managed to get X feature out during their last review cycle at Y cost with impact Z. This person will not need to deal with developer satisfaction, retention and performance. They will not need to deal with the impact the lower margins they pushed for had on the next feature delivery, or the continued maintainance of the systems. And if the dev team had to lower the quality too much in order to meet the quote they put out, that will be 100% their fault, the "business" will know not to use them for their next contract, or they'll expect the dev team to take on fixing all the issues at their own expense once more.

View on HN

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward.

These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"

> Even houses always go over time and money and that is fairly straight forward.

This is an incredibly important point. I was "raised" in commercial software at a time when there was a lot of condescension internally towards ourselves as an industry because we couldn't do estimation and planning, and building was the favorite comparison. A $100 million building couldn't run late or over budget. That would be unimaginable, and it doesn't happen because those people are too serious and professional to let it happen, not like us unserious, immature software doofuses. Turns out that was a complete lie, but at one time it warped the profession, because it made people believe the answers already existed, right around the corner, something you would figure out pretty soon just like last year you didn't know regular expressions and now you did.

The problem with that was that when somebody walked in with a button-down shirt, oozing confidence and saying they knew exactly how to consistently deliver software on time and bug-free, those people weren't laughed out of the room. Elaborate heavyweight processes, and their "lightweight" (hah!) cousins, could sell themselves as proven, established solutions. We could believe that bullshit because we had been fed the lie that other industries had conquered these problems.

I've seen a lot of industries compared to programming, like construction and manufacturing. For example, people trying to apply lessons from the Toyota Production System to programming.

This doesn't make sense, because we have systematized the construction of executable programs with extremely high reliability and predictability: we call it "Copy File"

It's the design that is the hard part, and the process of coding is the process of iterating on the design. Even turning the design into an executable is extremely reliable, either running via a VM or scripting engine, or compiling. Those are all very repeatable and reliable.

There are other disciplines that focus on creating and improving designs (like writing, painting, architecture, 3D modeling), but it's not like they're reliable or predictable either, unless you're designing very similar things over and over again. That's true of coding as well, but you don't really end up doing that, because once you've done it 3 times you should make a library and then never do that part again, just the unique bits.

In short, yeah, coding is its own thing, and I doubt it'll ever be predictable unless you're wasting a lot of time and effort doing very similar things over and over.

This point was recognized quite early. there is an influential article by Jack W. Reeves from 1992 [1] that looks at the manufacturing analogy and argues that "the code is the design" whereas the "manufacturing" is just the compilation and packaging (that is, super cheap and automated). I believe it‘s this line of thinking that inspired Agile practices, where software developers are seen as engineers rather than code monkeys.

[1]: https://www.developerdotstar.com/mag/articles/reeves_design....

> It's the design that is the hard part

Design but also requirements. You don't really know what should be built until you have a prototype. And estimating how long it will take to come up with a prototype that does what you think it should do, in other words coming up with requirements, is just the snake eating its tail.

I like to compare programming to the marketing industry.

Highly creative work and when deadlines are involved the work becomes spurty (sprints) with corner cutting (scope reduction) to meet unrealistic and over committed deadlines.

Yes.

Coding is not like assembling the machine. Coding is like inventing the machine.

It doesn’t even have to be a big construction project to hit budget and schedule issues. Rebuilding our house had us going right back to the drawing board having to get new plans drafted and approved. It worked out much better in the end but the unforeseen cost and time overrun was quite anxiety inducing at the time.

But yeah the idea anyone has magically solved accurately predicting the future is completely bonkers.

I like to remember "plans are useless but planning is indispensable". The plan is useless because of the challenge of predicting the future. But the planning is useful because trying to predict the future gets you asking good questions.

What is then terrifying to me then is when I find myself working with people who manage to, by way of treating "estimates" as "quotes", make it so demoralizing to plan anything--as it will be "used against you" later (which they do even if they were adamant they wouldn't)--that everyone does everything they can to discourage and sabotage any attempt at planning, because planning is valuable :(.

Also because planning gets you to make your desires explicit and to put them in a useful framework. Unexpected problems, disruptive as they may be, don't usually derail the whole plan. Some parts may need to be rethought, but others are still valid, and the whole thing keeps you focused.

There was a submission on this (in the annals of HN) where someone made the point that, more often than not and under normal project scenarios, unexpected problems usually do derail the entire software engineering plan.

The gist being: estimates are given with zero as a lower bound, and some upper bound. In reality, there is no upper bound. Software engineering can and does involve unexpected problems that would take infinite time to solve.

Ergo, project timelines are more accurately averaged between {min_time} and {infinite}, and, given that, remaining risk is the only true metric that should be reported. I.e. how far are we along in terms of project completed, such that we can say only x% of the project remains, and therefore that 1-x% did not explode.

The fundamental problem with estimates is that the recipient believes that the estimate will always turn out to be true, which is obviously not correct.

So, why can't we express the upper bound in combination with uncertainty?

Example: "There is a 50% chance that the feature will be delivered within 1 month."

As time progresses confidence starts increasing and we get closer and closer to how much time it actually takes (be that 5 days, 5 months or 5 years). On the day the feature is completed, confidence is 100% because the real delivery date has become known.

Programming is isomorphic to theorem proving (according to Curry-Howard).

Therefore trying to estimate a software project is a bit like trying to estimate how long it will take to prove a new theorem in mathematics, assuming you would know which exact theorem you want to prove.

Er, isn't it just getting your program to typecheck that's equivalent to proving the theorem (by construction)?

I tend to find this isn't the main consumer of my software budget :-)

In a way I think yes but just getting the type-check right would be like proving ANY mathematical theorem. It is very easy to prove mathematical theorems if you don't care what those theorems are.

The challenge in mathematics, and programming, I believe, is what ("lemmas") to prove so that you can then prove more things that are useful for engineering, science, etc. . What functions to write in your program so that you can get its "main function" to do something useful.

Add to that the fact that much of the "type-checking" with current practical programming languages still has to be done informally, to describe what we expect of the result and then prove (to yourself and the client) that the program does that.

A lot of the thought-process that goes on in programmers' heads is informal reasoning proving things to yourself, "If I make this change here then that thing there must have a correct value, and then ..."

its more than that. there is a loose correspondence between plan and work. so changes in plans can often be projected onto changes in work. the same goes for expectations and dependencies.

the other thing about the plan is that it attempts to capture what completion might look like. where i come from, the things software developers do right before releasing code look very different than the things they do when they are starting a new project. the plan can allow you to try to do some orchestration, ensure minimum quality bars are met, etc.

having a fuzzy map of the future that you're constantly having to correct sucks. having no map at all leads to the kind of carpe diem development organizations that never seem to finish anything.

More than that we need to be flexible to adjust a plan. You’d be amazed at how many people who quote that aphorism aren’t actually flexible. At least with a building they are also motivated by not leaving a physical monument to their failure.

I'll raise (shrink) you an estimated-at-1-week landscaping project for my house that ended up taking just over 2. Wasn't particularly anxiety inducing, though, as we expected some overrun and both parties (re)negotiated in good faith.

Oh man, this hits home so much.

I used to lead a software department in a small company that sold software to, mainly, the construction industry, so the go to comparison was building houses, which according to my boss, were always on time and on budget, unlike software.

The funniest thing about it was that our software was used by huge projects: Hinkley Points C, HS2, etc ... which obviously have an great track record of being on time and on budget ಠ_ಠ

From what I've heard, in construction most of the delays happen with the foundations.

Everything that's below the ground is hard to predict, because you seldom know exactly what's in the ground.

Once your construction has progressed above ground, it's somewhat more predictable.

(But delays are still possible.)

There's also the problem of of a company working on multiple construction sites in parallel.

In software engineering, this also happens of course, especially if you develop in house. And you also need to factor in the maintenance, as it's usually performed by the same team.

I think that adding a feature to an existing software product is more like adding a new floor to an existing house.

Sometimes it's like adding a new floor to an existing house in between two of the existing floors without any of the occupants noticing.

'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'.

In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting.

In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc).

Engineering is obviously different... what's the measure? LOCs? Obviously not...

Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.

I think you're talking about goals, which isn't the same as estimates.

A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area.

But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.

Sales team certainly understand the sales cycle and different velocities involved.

Eg - two jobs we ago sold to finance playera from small hedge funds to huge asset managers to central banks and finance ministries. You could sell more small hedge funds by knocking on more doors but you understood that the big players took months and years to decide. And of course we always tried to hone the sales org and process to arm the sales people with tools and data to move faster. We certainly held them much more accountable than devs.

It's actually not a fair comparison - software development is often like golf - the only limit to your velocity is you while sales can't really move faster than customer's process in many cases.

(Yes I obviously know dev processes can have external dependencies too)

> the only limit to your velocity is you

I have never seen this to be the case outside small, self-contained projects. Even with a fixed scope (its own can of worms), major slow-downs often clearly come from outside the team—unexpected or unreasonable infrastructure limitations, problems with the products of other teams, shortcomings of internal or external tools and libraries, unclear or inconsistent evaluation of the work by its eventual users... etc.

Moreover, in cultures tied to estimates-as-quotes (or estimates-as-deadlines), there is often significant pressure for "product" teams not to try to fix these problems, even for themselves. It would be net faster for us to write our own version of X than to try to integrate the work of team Y? But they've already done the work, why would you want to do something redundant?

In a world where technical teams have clear ownership, this is less of a problem. Team Y giving you problems? Work around it the best way you can. Infrastructure not supporting your needs? Hack together your own on top of lower-level pieces until it's ready. But organizations with cultures that give technical teams the space to do this also have far less issues with estimates—both in having better estimates and being able to handle estimate uncertainty gracefully.

Moving faster and increasing impact of deliveries, those are goals you can work towards, that do not involve needing to estimate anything.

The question is: do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?

// do you for every sale provide an ETA of when you think the sale will close, with projected key milestones along the way and their dates, all before even beginning engaging the would be customer?

No because that's kind of useless.

With software, the estimate is (or should be) part of the go-no-go decision for the project. "Oh, it's gonna take us 10 years to build this? Maybe we should reconsider"

Yes, it's like that. You have to move deals through many stages. There's expectations of timing into each stage in addition to quota. Most places will fire even senior sales people if they don't perform for a few quarters.

"$$$ closed at the end of the period" causes negative externalities at the expense of value delivered in the long run (overpromising, misleading, mispricing). This isn't unique to sales/engineering, I've heard of it playing out the same way in "factory" law firms where sales-lawyers and delivery-lawyers are separate.

> at least there is a very objective measure ($$$ closed) at the end of the period.

That is far from an objective measure standing alone, unless every salesperson generates all their own leads and the distribution of potential leads is random.

But generally your more experienced members will get the bigger potential customers.

So now you're back at square one trying to judge their success in relation to the anticipated likelihood of their leads.

i think well run teams in general have a lot in common. Not just sales or engineering but all well run teams.

I used to work for a company that sold custom business systems. When the customers did their parts, i.e., signed of specifications and did their acceptance testing within schedule, we usually delivered within estimate and in time. This was of course applications built with boring technology where 80% was simple CRUD. But the market for this should not be underestimated.

Sales teams do EXACTLY that. Go into salesforce and you’ll see the estimates.

Potential deal with client Foo will be for $X, to be signed on Y day, with Z% chance of closing.

On an individual level, it may be more precise than it is accurate, but it’s a fairly standard and important part of sales operations. And yes, the estimate dates are often just ways to express orders of magnitude (put next Friday as estimate dates not because it’ll definitely close next Friday, but bc it’ll probably take about 2 weeks). The % chance of closing are typically pre determined by what stage of the deal you’re in.

However, when applied across dozens, hundreds, thousands of potential deals, it allows the organization to understand their sales pipeline and sales velocity fairly accurately.

Of course the numbers are gamed a bit. And some sales people are much worse at estimating than others, or less consistent about keeping the numbers up to date. But the benefit of these practices are massive.

Houses have been done before. Enough time that we are good at those estimates. Once you have built the same house a dozen times you can estimate to within a couple hundred dollars. Contractors do this all the time for spec houses. Spec meaning that they are building it and the planning to sell it once it is complete. I know several contractors who do this all the time. They have never had someone order a spec house and come in anywhere close to the estimates. Everyone goes over the light fixture budget ($600) by at least $3000. Similar for the kitchen and bath fixtures. It isn't unheard of to double the cost of the house on seemingly minor upgrades.

> These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years.

Then you must be either an independent contractor or have some magical source of job security. I couldn't get away with this kind of estimate.

Probably more to do with personality mix than circumstance. I've had bosses where I could say things like that and get away with it. I've also had bosses where if I said something like that, I'd be packing up my desk.

Ok, granted, an enlightened boss might accept that kind of estimate, I suppose. And without the higher-ups breathing down his/her neck.

If you give a bonus for getting done on time/early, construction will finish pretty darn close to the estimates. Construction is underbid at least partly because the incentives are setup for underbidding.

A lot of the rest is Planning fallacy[1], particularly with individual contractors, but larger contracting businesses can absolutely come up with realistic estimates based upon past experience.

1: https://en.wikipedia.org/wiki/Planning_fallacy

Estimating in terms of units is mostly for internal teams with a fixed payroll. It can work really great in that context. But imagine that you are asking for project funding. The person across the table logically wonders: how much do you need? You yourself logically wonder: how much do I ask for? In that environment, can either party really accept “who knows” or “5.5 units” as the answer unless money is not a concern for anybody?

In my opinion, the estimate gives them a sense of scale. If some small number of months would cost too much, then you know and can start to have an investigation project of a week to better help define what should be in and what shouldn't.

They do treat sales people that way. Sales is ruthlessly managed and expectations are very important, especially at a public company.

At least for government projects the 'wrong' estimates are intentional. Admins always take the cheapest quote, so to earn money everything happening during construction has to be 'out of scope'. Like winter, or different soil layer than specified, or whatever.

Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their marketing budget. The customer care agent that gets shouted at because feature xyz is broken / not working as the customer expects, would like to give the customer an answer when it will be fixed. The customer care manager is also worried about her team members‘ retention.

So having a rough or concrete time line / roadmap is helpful for these parts of the business.

I also believe that a feature request is incomplete without an estimate. It is like a friend asking you to go buy him a car. What does he need a 3000$ subaru from 2003 or a 2021 Ferrari? Of course the friend can give you an insanely accurate list of specifications, but giving you a budget + some guidelines will probably be more effective for your friend and more fun for you. Especially considering that you know much more about cars (read software) than your friend. Knowing the budget you will be able to make much better choices.

If you take the allegory of a quote (which I think is correct) then you need to consider that the haggling process always also includes scope of the product. „I‘ll give you 5000$ for the car, but only if you include a free car wash“. And you can always use an estimate as defense against feature creep. „We are running low on budget, I suggest descoping xyz into the next iteration. Otherwise we won‘t be able to ship on time“. If on time is not defined then you can never have this conversation.

Agreed, marketing (and everyone, really) needs at least rough estimates. Software is notoriously hard to predict. As time goes on, estimates get updated as more is known about the problem and the org's ability to solve it. So, by definition the first estimate anyone makes at the beginning is the least reliable one, by a long shot, but it's something to start with that gets refined as time goes on.

I think where companies can get in trouble with software is when the initial rough estimate somehow gets blessed as the plan of record to cement in everyone else's critical path, and subsequent estimates are treated as engineering screwups rather than more informed predictions. I don't know what the solution is, because stuff like this can happen with everyone involved being super competent and having the best intentions. And sometimes there are engineering screwups, neither side is always blameless.

Power imbalances between organizations are where natural creative conflicts go bad. In a less healthy company, whichever org is on top politically tends to be blameless, whether it's fair or not, which ultimately hurts everyone's ability to do their best work because conflicts between orgs are less likely to be resolved based on what's best for the company or project as a whole. In ideal companies, orgs are balanced such that they can push back on each other for good reasons, but not for zero-sum, shit-rolling-downhill reasons. I'm pretty sure ideal companies only exist briefly or never though.

And to continue your metaphor, most software estimation comes from someone describing a car they like, and based on your mock ups you and others decide on a price, how long is acceptable to build, etc.

So then you goto build the car and everything's going great till you find out that the latest research shows the specific design of engine you're using doesn't work with the eco friendly fuel that is now being mandated by the government. And suddenly killing cows is uncool so you have to change all your chairs to fabric or source fake leather, but half of your company thinks that endorsing fake leather is hide-appropriation and you're now spending a third of your time in HR going through training.

And eventually you get about a week out from delivering the car and the customer calls your PM and says they want the car to have a top speed 30mph over the original specs while maintaining the fuel efficiency rating. And the doors should swing up, instead of out. Like billionaires'.

Kinda. Except that's "need for a definite date" is an expectation that they could be flexible about if forced. If other professions genuinely understood that software estimation is inaccurate by its nature and that accurate predictions of completion dates are, by their nature, impossible, then the uncertainty can be managed.

But because it seems so simple to estimate how long a piece of work will take for everyone else, it's really difficult to get other people to realise how hard this is.

I've sat in meetings saying "I don't know how long this is going to take" repeatedly until the rest of the organisation works out that they're not going to get a definitive date. Then suddenly the marketing team plans for "OK, well if it's done by this date then we'll have enough time to make this trade fair. If not then we can skip that and do the other one". They'd like to have a definite date because it makes their job easier. But if they can't have one, they can work around it.

> I also believe that a feature request is incomplete without an xestimatex delivery date attached

This is so true, as long as the devs have control over the scope. "We don't know and can't predict how long it's going to take to build the thing. If we can't build it all by the deadline, what's more important: delivering something on the deadline, or missing the deadline and delivering the entire feature set?"

To use your car haggling analogy: You've given me $5K to buy a 4-door car less than 5 years old. If I can't find one like that, what's more important: the budget, the doors or the age?

That's the thing, if other departments have a timeline they need that should be the estimate.

I think it's a lot more natural in business software to say something like "we need the best version of XYZ you can do in three months" rather than saying "we need XYZ" and hoping the estimate is three months. That way everyone's cards are on the table and can work together on getting what they need.

I need to know what the stock market is going to do next week. Otherwise, how am I going to become a billionaire? My broker’s refusal to tell me literally costs much more than all the returns he’s ever generated. Who does he think he is?

I once had a manager that thought he could negotiate estimates. That is like negotiating with the weatherman about the weather. Sure, maybe in the end you can convince them it will be finished sooner. But the fact is that it really doesn't change reality.

Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another.

- does it have to be instant or can we run it as a batch

- maybe it’s enough to have this tool in English only

Etc.

Negotiating scope is a different mindset than negotiating estimates.

Even better would be making sure the team understands both the real goal they're trying to achieve and how time plays into it, letting the team make scope trade-offs like that as they go along.

All discussions about estimates are really just discussions about scope. I try to make that as clear as possible when I'm talking about time estimates. There is no 'negotiating' estimates. If someone is being a little pushy with trying to get a shorter estimate, I will always just rephrase it as a trade-off. 'Doing it in fewer than X months would mean dumping X feature/walking back on Y commitment,' whatever the case may be.

I think in general these conversations always go better when you make the other person feel like they have a choice. Really, in today's corporate world everyone is playing CYA at all times. The person trying to bring down the estimate is probably doing so because they are anticipating what their boss will say. By listing potential trade-offs for them, I'm helping them by giving them fodder for that talk that they'll be facing, and they'll be able to give their boss a choice.

You always get better reactions out of people when they have choices, rather than just presenting a stone wall to them. Having said that, some times the person will really just keep being pushy, and then fortitude is necessary. If you are someone who has trouble definitively saying 'no' when it's required, you're doing your team a disservice by being the person giving estimates. You really need to never slip with this; all it takes is for you to one time cave and say, "okay, maybe we can try to shave a week off" and now that person knows that your estimates are negotiable.

If you consistently phrase them as facts rather than bids (like the sort of estimate a contractor gives you for a house), you'll get better results.

You can tell when they are negotiating time instead of scope. It will be something like "surely we can do this in 2 days not 5?" Instead of "we probably will take 2-5 days to do this but need it in 2 so something of 3 days needs to come out somewhere else". The first one is saying 'work harder and just do it.' The second is 'ok it may take 2-5 days but lets pull something else out to make up for the deadline we want'.

I found orgs that negotiate time did not talk to their team in the first place. Then went on to promise something on behalf of the team. Now they do not want to eat the humble pie of 'I ran the numbers and you only get half' instead they get it going and just overbudget on the thing. Which just makes everyone in the process mad.

I think this is a vital point. Estimates help narrow down what is important and what isn't.

Maybe you want features x, y and z. If it takes a day then X is worthwhile, if it's going to take a month don't bother. Z must be done so if that's going to take a long time we need to drop y.

One of the best product owners I've worked for would often ask for estimates and base plans and features from those. Some things would be easy technically and valuable, others harder and just a nice to have (but worth it if it only pushed things back a day).

I remember an interview at a well known tech-ish company where the question started out as “Estimate this project” with a good description of the scope and team. After I said something like 4 months, interviewer said, “OK. The CEO says it needs to be done in 2 weeks. What now?”

I thought this was a basic project management question about trading off quality, scope, schedule, staffing, etc. and offered the usual suggestions of cutting scope (nope CEO demands entire scope), cutting quality (nope can’t compromise quality), increasing the team, contracting out, reprioritizing and realeasing P1s in 2 weeks (nope, nope, nope). Obviously I didn’t get the job.

Later I learned from an acquaintance inside the company that the right answer was probably “Work the team 24 hour days, nights and weekends, for 2weeks to deliver what the CEO wants. I think I dodged a bullet there.

In my experience, the sort of people who believe in negotiating estimates are also the sort of people who only believe there's one dimension that can be traded off: how much unpaid overtime will the developer work?

I hate to sound cynical, but it can change reality if he were to use the estimate to extort overtime out of the team by citing their own estimates. I don't think it works out medium to long term, but could help him short term with the right teams. I assume they were also hiring for pliability/submissiveness.

The big cost tends to be software quality as it is less visible/harder to measure than dates and scope.

In practice, the lower you can get the estimate, the more it will shoot back in your face.

I can say that this company had the worst planning I have ever seen, with some project not being able to finish at all.

I find it much less stressful to deal with since I've made peace with the fact that some managers want to be lied to.

Be careful because those lies become expectations for everyone that manager speaks to.

Yeah I've had a couple of managers try this. I always tell them my estimate is how long I think it will take take. But if he believes that estimate is incorrect he's welcome to modify it as he sees fit. (Over e-mail of course).

Sometimes they'll modify it, sometimes they won't but at least I won't have to argue about it or get in a situation later where suddenly they pretend like their estimate is my estimate.

You and I act like weathermen in this situation.

But plenty of engineers do estimate based on what they think they can get away with or other negotiable ways.

I used to be a non-technical manager “managing” a team of developers. I later (through circumstances) became a developer. Looking back at the games my team played with me I can see why many managers are cynical about the estimates they are given and attempt to negotiate.

I always overestimated because it was the only way that I could ever devote anytime at all to technical debt reduction.

I'd say you're including necessary maintenance in your estimates, not overestimating!

Not claiming it applies to you, but a lot of managers don't understand the difference between an estimate and a deadline. It comes back in all kinds of weird ways.

Sounds like the type that thinks that if they blow enough smoke up your arse then you get things done quicker, and they look better. I hope they die out.

They did die out. Their planning was crazy, promises to customers never achieved, some projects even completely cancelled because of major overruns etc.

They also started doing their own estimates since they didn't like mine. 3 months of work with 3 people -> 1 week of work 1 developer. Not kidding about this last one! We didn't finish it in 3 months because of scope creep.

Yeah they went bust.

at that point you are negotiating just how much of your personal time/stress you are going to burn to meet their expectations. Also maybe how many other people you are going to have to short change because they have jumped the queue.

That is the degenerate scenario, but it’s not always true.

Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it.

And I’ve also seen wise use of estimation but that is rarer!

> And I’ve also seen wise use of estimation but that is rarer

I've got a question for you here, what is a wise use of estimation?

What problems are estimates the ideal solution for? In the context of software development?

I can think of only two: planning headcount and priorities (aka planning the order in which you do things).

When you focus on those problems, you realize there's no need for an accurate estimate. All you need is relative sizing between requests. This seems twice as much work as that but gives us half the benefit. Ok probably we shouldn't do this one first. And even then, often time impact is all you need for priorities. Like who cares what takes you longer, if you just focus on building the next most impactful thing you'll very often succeed.

The question of: "When are we going to be done this?" Is almost always irrelevant except for what I mentioned "asking for a quote". Like, who cares when it's done? What else you'd rather we do? I can tell you if your alternative will be any faster or not. And is this not the most impactful thing? If so, let's finish it and stop slowing us down with these irrelevant questions.

Now for headcount, it's the same thing. Look how much you did last year with what headcount. Ask yourself if what you're hoping to do this year is of the same relative size, twice as big, half as big, or smaller? And then plan headcount accordingly. If twice as big, double head count. Overtime you'll learn if twice as big requires doubling headcount or 1.5x or 1.2x or 2.3x etc.

Who cares when it's done? Often there are external deadlines like a start of production of a car for example which can not realistically be moved because too much planning would need to be redone and too much disruption would cause so much overhead that it could break a company.

Also when price and time are fixed, there is only one thing left for negotiation and it is the amount of features being delivered. Sometimes people have a hard time to cope with it but if you do it correctly it's a great thing for everyone. The most important features could be delivered early and the closer to the deadline the non critical features can be implemented which are nice to have but won't break the product if they're not in place. That's a great way to bring as much value as possible without breaking anyone.

Wise use of estimation is projection. You don't need to do much more than count stories. It would be honest and without agenda.

I've never seen it either.

Yes exactly! When you ask someone for their estimate, you're getting a quote from them.

When you actually want to predict the length of time something will take, you rely on historical data and create a projected forecast. It never involves asking somebody for their best guess. That's how every single "other thing" we predict is handled, so why is software done differently.

Actually, I've seen some of these ideas being talked about in KanBan circles, like tracking lead time and cycle time, and then using monte carlo simulations to forecast, but I've never actually seen them in practice.

Didn't Joel Spolsky implement it all the way back in the stone age... er, 2007[0]?

The idea is old. The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level. Perhaps as an individual, intimately familiar with the problems you encounter, being able to introspect your own thought process - perhaps you or me, we could learn to estimate better. Except the existing popular tooling absolutely sucks at facilitating that.

[0] - https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

> The problem is, in many software companies, none of the tasks look alike. So your past data is going to be somewhat dirty, particularly at team level

Tasks don't really give you anything though. I think if it was measured in terms of features, that would work a lot better.

And with a Monte Carlo simulation, you get to know the time it would take you to complete any random feature on any random period. So maybe you can't perfectly predict that next feature, but in the year, on the average, your predictions should tend towards good accuracy.

And you could take it further, machine learn the feature request to the time it took. And then run the ML inference on any new feature request. Maybe let devs add some labels, it's not exactly estimating, but they could mention if say they think something is "complex", "ambiguous", "straightforward", etc.

I'm sure there'd be ways to do it.

Monte Carlo here is just a way of adding together estimate distributions without doing any of the fancy math. The variance of resulting compound estimate strongly depends on the variance on inputs.

Feature-based estimation seems to coarse to me. Not only none of the features is ever like the others once you dig into it, they're also interconnected.

Get something ready for Christmas business? Get a car on the road? Finish the cruise ship in time? ...

> In the context of software development?

While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing".

Is that correct?

Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?"

That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example.

My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.

I have seen two software examples first hand. Usually it's because a feature can have much more value at a very specific date.

The first one was a feature for one of the minor verticals of the company product. Basically, something that would be nice to have and would be done eventually, but not a priority. However, the big annual trade show for that vertical was coming up, and the company could have a slot for a conference/demonstrate a feature. Marketing/sales were pretty convinced the aforementioned feature could be a big hit at the show, and provide lots of exposure. So we were asked whether it was possible to have it ready by then. If we could, then it would have a lot of value and would be priority 1, otherwise back to the backlog because it would be much harder to advertise it outside of the show.

Second example was caused by the reduction in VAT in Germany last year. Having internationalisation/German translation all of the sudden became pretty valuable because that would help push even more products in Germany.

I haven't seen this issue arise very often in software

No? Maybe not if you're a software-only company. But for pretty much every hardware (a gadget, a car, a rocket, whatever), the software is part of it and it aint working until the software is.

If you don't want your product to be held shipping because the software isn't ready, you better have some way of estimating when it's going to get done so you can either trade features, personell, or even just knowing that there's no point rushing the hardware because it'll be done way before the code anyway.

Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going.

There's tons of things that require broadly knowing when X is going to be done beyond capacity issues.

If you create low quality estimates willy nilly then don't be surprised that you will break them.

The above are reasons a business needs estimates / rough delivery timelines. I'm not sure how my discussion of the value of estimates is relevant to the quality of them.

To get a rough idea of what work can be done in the next X weeks, so that the business can forecast.

The wisdom comes in knowing things can change and it's just an estimate. The process of estimating is quite good as it requires finding out a lot more about how you will solve something, and planning things in advance.

> so that the business can forecast

Forecast to what purpose? What is the business actually trying to achieve for which they believe, maybe wrongly, they need accurate software estimates?

I never experienced the dynamic you are talking about. Sounds like your workplace is terrible.

I've almost always had business partners that were just that - partners - invested in the product and the team long term. I am the same way now that I am "the business."

Estimation is a useful forcing exercise for thinking through what something takes, identifying risks and hard parts and deciding upfront what to do about them.

It also becomes a good measure of people's integrity - what they do once it's apparent the estimate is off. 100% of the time, when engineering came back saying "we underestimated X, it's much harder" - it was totally fine.

I have noticed this article during the "Parkinson's law of triviality"[1] meeting (within phase where technical guys are typically silent) and almost started laughing when someone asked about "over the thumb effort estimates" (that are always becoming carved into rock deadlines).

It really made my day :)

[1] https://en.wikipedia.org/wiki/Law_of_triviality

This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level.

TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out.

Personally I offer my customers to either pay by the week, or pay by extremely fixed scope with a 3 month definition period up front and a 50% buffer above the estimate. I stress that paying by the sprint lets them change objectives at any time, gives them an always-current report of how much "effort budget" they have left to work with, and guarantees they only pay for what they use. That felt like a risky move the first time I did it, but I never lost any business over it.

I think that everyone still converts what-ever-unit used to time. For example, from one of my earlier jobs, we had "T-shirt"-size units, ranging from XS to XL. It took two weeks after introducing them until someone figured out that XS is two hours, so in a sprint you should be able to do $SPRINT_DURATION / 2 XS tasks. And then the person figured that S was equal to, say 4 hours and so on and we were back on square one. But we didn't estimate in concrete time units. /s

There may be a lot of uncerntainty in Data Science and ML projects. However, recently I started feeling like I actually have it better than someone from pure software engineering sides of things:

For either, there is often a function from time spent to quality. 100% perfection is basically impossible and before that the function increases very slowly, seemlingly logarithmicly.

For SWE, expectations are often close perfect solutions. Too greedy effort estimations cause a lot of trouble. For DS/ML, however, perfect is usually off the table and this fact is widely (not universally though) accepted. When it is accepted to give estimates in this way, suddenly there no harm from being quoted on it and I really don't mind to give estimates anymore, where I just make a guess at a good 80/20 point. If I am wrong with that point, chances are nobody on the outside/higher up ever knows.

This may be different in domains where very clear targets have to be met (e.g., "self driving cars that pass lawmaker's requirements for use on the streets") and then I'd guess it is a true nightmare.

Like this, I never felt overly pressured by ML/DS deadlines over the last years. Some things were great successes, sometimes the quality wasn't great enough and projects were stopped or customers left. But there never really was a case where anyone thought that working extra long might have been an option to meet higher expectations.

I don't really have a solution for SWE, I don't really see how one would sell something like "I can do it in X time and it will only crash / stop working / make mistakes / become too slow / have vulnerabilities so often. More time will lead to fewer problems". This just isn't what's expected. But at least for complex systems and security vulnerabilities, I'd argue it is actually quite true. Guarantees for 100% perfection just aren't realistic. Avoiding the most obvious pitfalls is done rather quickly and the more time spend, the more is needed for further improvements.

I don't really understand what type of environment you're talking about.

Some parts seems to hint the devs are an outside consulting shop, and some parts hint that the devs are on an internal team.

Most internal teams can blow through dev deadlines over and over again for years without any real repercussions. And while outside dev shops can't blow through estimates like internal teams the individual devs usually can unless they're in a leadership role.

And of course once the dev team realises that their "estimates" are actually being treated as quotes, and that their ability to find time to vacation, sleep, or even see their families will be contingent on their quote being sufficiently padded...

Now you have a recipe for a highly adversarial relationship between management and engineering throughout the planning and development process.

I call it the "What's the earliest date you can't prove you won't be finished by?" management question.

Agreed that often times estimates are mistaken for quotes. Aside from that, my personal experience has been that those who work adjacent to software understands that there’s an element of uncertainty. If those that we work with don’t, it is on us to educate. Improving estimation will eventually improve quality of life for all involved.

Reply on news.ycombinator.com