I think, software development works best without deadlines, but then you have to find ways to finance yourself while people wait.
Software effort estimation is mostly fake research
81–90 of 318 posts
Re: Software effort estimation is mostly fake research
#82The 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.
Re: Software effort estimation is mostly fake research
#83"Estimates" are for things you've done before - like you can estimate building a house, because people have built houses before. The more like an existing house, the better you can estimate it. Software is invention and construction. The construction part is pretty easy to estimate. The invention part is ... very very hard. I'd like to say it's impossible. I'd like to see the software industry use a different word th…
You've perfectly nailed the fundamental issue here. For many software projects, you simply cannot make meaningful granular estimations for parts of them. It doesn't matter how many story-point poker sessions you hold. Some software work cannot be reduced to a positive integer. In our business scopes creep, bugs plague us, and myriad issues make precise estimations pointless. It's engineering Numberwang. I get that fo…
That estimation is hard does not make it impossible. That it may be inaccurate does not make it worthless. Special pleading that our industry is somehow the only one that faces uncertainty and novelty doesn't really hold water.
Re: Software effort estimation is mostly fake research
#84If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Apple executes massive feature releases on a yearly waterfall-like schedule across hundreds of teams. It requires honesty, transparency, strong leadership (ruthless prioritization), strong cross-team goodwill, strong cross-team collaboration as well as a solid body of experienced top-tier engineers. Other than that there's no magic. While there are teams within apple that does scrum/agile, none of the core OS/framewo…
That doesn't imply anything about estimates.
Do they tell you at the beginning of that cycle what features to expect? Or do they constantly work on features, and then at presentation time do a freeze?
Re: Software effort estimation is mostly fake research
#85If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
> ...nobody cares!
> Nobody learns.
> It's insane.
Estimation is really hard, especially if you're dealing with new challenges, new people, and new expectations. Throwing moving targets (unplanned changes) into the mix, as you noticed, makes estimation even more difficult.
The thing is, it very rarely is the case that a wrong estimate will sink a project. Things get delivered late all the time. No one dies. Most stakeholders aren't like two year olds throwing a tantrum because an unforeseen problem delays a deliverable by a few days (admittedly some are close).
The actual definition of failure also needs to be considered. Is it considered a failure because a project manager ended a colored gantt bar at a particular date and the actual time was longer? Or is it a failure because the customer cancelled the contract because a deliverable was not available on the agreed-upon date? Or is it something far more nebulous, like a slow death march towards a misguided goal that burns everyone out and compels them to sip artisanal coffee and daydream about leaving instead of grinding onwards and hitting targets?
Ultimately, people "don't care" because accurate estimates are not the most critical problem on their mind. Most of the time an accurate answer to "When will it [the deliverable] be done?" has about as much gravitas as guessing the number of jellybeans in a jar at a kid's birthday party.
Doing a retrospective and analyzing what went wrong when a project delivery slipped expectations is certainly reasonable but it so easily slips into a blame storm and/or people making commitments that aren't realistic. Getting straight answers from folks for this kind of analysis requires a level of psychological safety that just isn't present in most workplaces.
Re: Software effort estimation is mostly fake research
#86I wish as much attention was paid to perform post mortems regularly then to only do estimation. You know, actually look at "hey, this is what we guessed and this is what actually happened".
I've had to fight to actually hold post mortems, and every time I've done this, the manager ends up asking, "hey, can I share this?"
So clearly, there's value, at least when we've done them.
I'm amazed at how few places even perform a complete feedback loop. It's just, "when can you get this done?" and, "is it done yet?".
Re: Software effort estimation is mostly fake research
#87How do other disciplines estimate NRE? Do they have the same problems with missed predictions?
Sure. A lawyer may have a pretty good idea of how a particular task or case is likely to play out but there's a lot that isn't under their control. I imagine something like drafting a will is relatively straightforward but I also imagine a criminal case has a huge number of variables.
Re: Software effort estimation is mostly fake research
#88Earlier quoted context omitted.
You've perfectly nailed the fundamental issue here. For many software projects, you simply cannot make meaningful granular estimations for parts of them. It doesn't matter how many story-point poker sessions you hold. Some software work cannot be reduced to a positive integer. In our business scopes creep, bugs plague us, and myriad issues make precise estimations pointless. It's engineering Numberwang. I get that fo…
That estimation is hard does not make it impossible. That it may be inaccurate does not make it worthless. Special pleading that our industry is somehow the only one that faces uncertainty and novelty doesn't really hold water.
> "Special pleading that our industry is somehow the only one that faces uncertainty and novelty doesn't really hold water."
I'm sure you're right. I don't think we should abandon all hope. I just think we should be more honest. I also think that software has fewer constraints than other industries, which is a blessing and a curse for estimation
Re: Software effort estimation is mostly fake research
#89My problem with this is all estimation is hard. Period. Quantitative discussions of something that has been done? Fairly easy, if still not accurate.
Discussing something that hasn't been rehearsed before? You can really only discuss how long you are willing to work on it. Not how long it will take to get done.
Fun examples. How long would it take you to clean out your fridge? How long would it take you to learn to play a song on piano?
Re: Software effort estimation is mostly fake research
#90The 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…
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!