[HN Gopher] Communicating Software Estimates
___________________________________________________________________
Communicating Software Estimates
Author : wkirby
Score : 30 points
Date : 2024-11-18 15:56 UTC (3 days ago)
(HTM) web link (www.apsis.io)
(TXT) w3m dump (www.apsis.io)
| atoav wrote:
| Generally good advice, however I think the actual example phrases
| could still be clarified, e.g. bg explaining why clear estimates
| in software engineering are not as common as in other fields --
| note the person you are talking to might have a completely
| different experience in their field of work. And _then_ you give
| your buest guess and a clear explaination of your level of
| confidence, which factors could lead to shorter or longer project
| durations.
| nlawalker wrote:
| _> When you 're communicating an estimate the most likely mistake
| is that the other party considers it to be a commitment._
|
| The root cause is typically that you're communicating it to
| someone who doesn't _want_ an estimate. In that case,
| communicating the estimate with the commitment is often a mistake
| unless you 're willing to negotiate the commitment, because
| that's effectively what it invites.
| teeray wrote:
| The best estimates I've found are "This will take: days, weeks,
| months, years". No numeric values allowed. Yes, you can't do
| (inherently faulty) math on these estimates to arrive at
| aggregate metrics: this is a feature. However, it still allows
| you to meaningfully schedule work.
| nine_zeros wrote:
| The best way to estimate:
|
| "Wild guess - X weeks but could be X+Y weeks for unknown
| unknowns" (where X is 200% estimate in your mind and Y is 700% of
| estimate in your mind)
| cynicalsecurity wrote:
| Bad companies demand estimates.
|
| Good companies just live by a Steam clock.
| tyleo wrote:
| Having run a software team with good estimates, I'm disappointed
| in some of the commentary of, "just make up a long or obscure
| estimate." I don't expect a considerable amount of unknowns to
| come up in a project unless you have changing requirements or bad
| planning.
|
| You can't do anything about changing requirements so that can be
| forgiven. Poor planning cannot though.
| necovek wrote:
| It usually centers on whether changing requirements are due to
| poor planning or not?
|
| I don't necessarily think it is, and I believe it's easily
| fixed by keeping the reason (expected value) for anything close
| to any requirements being passed down to engineering teams.
| datadrivenangel wrote:
| Unreasonable stakeholders will absolutely hold you accountable
| to not meeting a schedule even when they're constantly changing
| requirements. And they can and will throw you under the bus for
| it.
|
| You are right though, that a decent team that does decent
| planning should be fairly accurate much of the time. And there
| are project management techniques to handle the remaining
| uncertainty.
| tuna74 wrote:
| If requirements change estimates change as well.
| perrygeo wrote:
| In theory, yes.
|
| In practice, if you try to change the estimate, you'll be
| shot down and asked to work harder. The people changing the
| requirements assume that software is infinitely malleable
| and any change is doable with a small amount of effort.
| After all the devs are smart so they'll figure it out, like
| they always do. To these people, asking for a change in
| estimate is indistinguishable from complaining or being
| lazy.
| datadrivenangel wrote:
| Yes, but stakeholders may not accept them... which is their
| problem, but they can make it your problem.
| srveale wrote:
| Chiming in with helpful rules of thumb I go by:
|
| 1. Never give an estimate in the same conversation in which it
| was requested, unless you're quite sure the answer is "less than
| an hour". Especially if they are going to turn around and quote
| your timeframe to a customer. The reason for this rule is:
|
| 2. The more you think about an estimate, the higher it will go.
| "Oh yeah and we'll also have to..." is 100x more common than "I
| found a shortcut that doesn't compromise on..."
|
| 3. Even if they know it's an estimate and not a deadline, they
| might not know the difference between "40 hours of dedicated
| effort" and "One week's worth of business hours". Making that
| distinction is just as important as the estimate/deadline
| distinction.
|
| I'm lucky to work where we don't spend much effort on estimates
| and time tracking, both of which just make things take longer and
| cause productivity-reducing stress.
| datadrivenangel wrote:
| The distinction between labor time and calendar time is an
| important one! 40 hours of dedicated effort is great, but most
| people parse that as "1 week" when in reality the available
| people may only be able to get 10 or 20 hours in a week due to
| other demands, or it's 38 hours of dedicated time that gets
| done in 1 week but the 2 hours of security and legal reviews
| take a month of waiting to finally get completed.
| msteffen wrote:
| When I switched from engineering to management, I spent a _long_
| time thinking about software estimates, read about many different
| approaches, and argued with many other managers (I'll try to
| write up my own blog post for the next time the topic comes up on
| here).
|
| The framing in this blog post is better than some (it at least
| discusses uncertainty) but I believe it's still basically the
| wrong framework.
|
| People (managers) like to assume that estimates are a random
| variable, and software projects are samples from project space.
| Estimates can be produced for a project by analogizing it to
| similar projects. This is not true at all. You cannot reason
| about software projects by analogy.
|
| Some assertions (that I will explore in said promised blog post):
|
| - Software development is _chaotic_ : arbitrarily small changes
| in the input (project requirements, who's implementing it,
| stakeholders, team, etc) may lead to arbitrarily large changes in
| time-to-completion (including "this project is now impossible").
| In short, any project may explode at any moment prior to
| completion.
|
| - The risk of a project is particularly sensitive to the engineer
| implementing it, and depends on that person's specific knowledge.
| Have they used these APIs or this database before? Any part of a
| project that the engineer hasn't used before represents
| potentially unbounded technical risk.
|
| - the way to manage this risk is to include buffer in the project
| timeline, and, critically, to use that buffer _not_ for
| development tasks that were harder than expected, but for re-
| planning and re-negotiating the deliverables with stakeholders,
| to un-explode the project. Agile builds this re-evaluation into
| the project lifecycle, which is the main (maybe only?) thing is
| does really right.
| necovek wrote:
| That's too much of a carrot IMHO: I would have appreciated it
| more if you dove deeper into one of those points instead of
| promising a blog post on a dozen.
|
| Edit: thanks for editing the comment to make it clearer what
| are your points. This makes my comment somewhat useless :)
| necovek wrote:
| I agree that the points you raise are important to realise and
| affect delivery duration significantly.
|
| I, however, disagree with that approach to managing delivery:
| if you tie in expected value with deliverables, you empower and
| enable engineering teams to smartly cut scope and deliver in
| shorter amount of time the biggest chunk of the value.
|
| It's usually only described as "cutting scope", but it requires
| real creativity and smarts on the engineering team (they can
| best tell what's feasible in remaining time, when they have
| tackled all the unknown unknowns you bring up) to do that in a
| way that still brings the most of the original value. If you
| move this to your "renegotiation" step, it becomes too slow and
| hurts delivery as well.
| msteffen wrote:
| I basically agree (I think) in that I don't think there needs
| to be a separate "cutting scope" phase--one should it as soon
| as they realize they need to. And I certainly agree that it's
| incumbent on engineering to invent alternatives and propose
| them when we realize that we need to cut scope (for the
| reasons you mentioned).
|
| FWIW, though, engineers shouldn't decide what to cut (i.e.
| _choose_ alternatives) in a vacuum, in my experience. I've
| been in plenty of meetings with product /sales/support where
| they say "it's better for the whole project to slip than to
| release it without this one detail" or "we would give up what
| seems like basic usability to get one particular piece of
| polish"
| rixed wrote:
| I find your framing interesting. But most importantly, even if
| nothing changes in the requirements or the team, the mere new
| information that is learned while implementing the project is
| often enough to change the estimate considerably.
| msteffen wrote:
| Yes! In my last role, I aggressively pushed the concept of
| "technical risk" to try and get people used to this idea.
|
| Sometimes the computers don't work the way you thought they
| did at the beginning. This is a normal and ubiquitous form of
| risk that just needs to be managed like any other type of
| risk, with prototypes, multiple revisions of the
| implementation (each introducing additional risk),
| occasionally re-scoping, etc.
|
| People outside engineering sometimes don't like it because
| the risk is human in origin--it comes from engineers not
| knowing things, and our job is to know things--but until
| there's an omniscient engineer, this risk will continue to
| exist.
| nine_zeros wrote:
| - the way to manage this risk is to include buffer in the
| project timeline, and, critically, to use that buffer not for
| development tasks that were harder than expected, but for re-
| planning and re-negotiating the deliverables with stakeholders,
| to un-explode the project. Agile builds this re-evaluation into
| the project lifecycle, which is the main (maybe only?) thing is
| does really right.
|
| This is the only right answer. Unfortunately, engineering
| leadership is too detached from understanding how software
| works. They think of projects like contractor painting jobs. So
| easy to estimate - sq. ft * number of people * number of hours.
|
| But software is not like that. Software is constantly changing
| every hour, every day. As a result, any estimation is changing
| every hour every day.
|
| The best thing is for leadership to start acknowledging the
| realm they are dealing with. If they can't they should step
| down.
|
| But realistically, engineers should always give 400% padding
| with estimates. The root cause of this estimation is poor
| leadership. It is not engineering team's problem that detached
| management doesn't understand software.
| akomtu wrote:
| An estimate is really a probability distribution, that often
| resembles a Gaussian distribution and thus can be captured with
| two numbers: the average and the variance. Combining multiple
| estimates together would involve some math around these two
| numbers. But the surprising thing is that managers in the
| software industry don't really understand probabilities, and to
| make it understandable those managers want to reduce the model to
| just one number, and when this model fails to capture the
| probabilistic nature of the underlying process, they attempt to
| overrule the math with authority.
| mikrl wrote:
| >they attempt to overrule the math with authority
|
| It's entirely possible to turn that to your advantage, but
| takes some luck/skill, not dissimilar to profiting off of stock
| market crashes.
|
| The asymmetry between mathematics and authority tends to favour
| the math.
| jbay808 wrote:
| This is correct, but the distribution is usually more like a
| lognormal than a Gaussian:
| https://thesearesystems.substack.com/p/task-estimation-conqu...
| lifeisstillgood wrote:
| What is an estimate for? It is really an estimate of _cost_ where
| big-O is mostly developer cost and that gives a handle on the
| next part _priority_.
|
| Both of these then add up to an _illusion of control_.
|
| Software is quickly becoming the largest moving part of many many
| organisations - and trying to control it is likely the wrong
| approach
|
| Software is a form of capital just like a robot on the Tesla
| assembly line. That robot and the software being estimated in the
| article are to do a specific job in a specific environment- an
| investment that will enable more production than without. But all
| capital rots - or rather depreciates. Taking a nice view you can
| have 10% on maintenance and repairs (but realistically more than
| that).
|
| Don't try to estimate these - don't ask your handyman for a Gantt
| chart for a hundred tiny fixes - just get them done.
| datadrivenangel wrote:
| Combining Software time/cost estimates with value estimates make
| it even more fun, because most software is low value (with some
| chance of being extremely valuable). Combining these into an ROI
| probability space makes everybody sad, but the expected value is
| still positive even if the most likely outcome is software that
| wasn't really worth paying for!
| tuna74 wrote:
| A more interesting question is how you follow up on your
| estimates? How can you improve if you don't track and reflect on
| the actual result on what was estimated?
___________________________________________________________________
(page generated 2024-11-21 23:00 UTC)