Live data from Hacker News

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

71–80 of 318 posts

Re: Software effort estimation is mostly fake research

#71

I find this amusing. Know how much a Honda Accord costs? About 25 Grand. Know how much a Mercedes S450 costs? About three times as much. They are both great cars, that will be rewarding to own. The Mercedes doesn't have 3 times more parts, but it probably took four times longer to make, and they paid the folks that make it, a lot more than the Honda. It's actually, probably better "bang for the buck," although it won…

Your base assumption seems to include that quality is valuable for its own sake. I don't totally disagree, but I'm wary of assigning value based on effort rather than output. Depending on why you are buying a car, the Accord is very likely much better bang for the buck than the S-class Mercedes. And depending on the situation, the prototype is often better value than the shippable product.

You are exactly correct.

That is why Honda is a bigger company than Mercedes. They do decent quality (Hondas cost more than Kias), but at scale.

I worked for a "Mercedes-level" photographic equipment company for years. People were often quite surprised, when I told them the size of the company. It was like Roadhouse "I thought you'd be bigger."

Our prototypes were incredibly expensive. A $2,000 (retail) body prototype would be insured at half a million bucks.

I just find, in my experience, managers expect Mercedes-level quality, for Kia (not even Honda) prices, and (if you are lucky) mature Honda assembly line development speed.

That can lead to real Jurassic-scale disasters. If you want that level of quality, you need to plan for it.

I'm working on the app that I'm doing, because I was helping a friend of mine evaluate contractors for his dream.

The promises they made were absurd. After a couple of these, I just said "Screw it. I'll do it for you."

He'll be getting Mercedes quality, but he'll need to wait a bit longer for it. I am pretty good at doing damn good; damn fast.

But he also won't be paying a dime for it, so I think he's good with that.

Re: Software effort estimation is mostly fake research

#72
post #57

Earlier quoted context omitted.

Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations. Add an estimate that you multiply by three in front of each, ie. if the dev…

Back when I was a product manager, there was an engineering manager who would drive me crazy. He had this idea of a 90% schedule, by which he meant a 90% chance of hitting if everything went as planned. Everything never went as planned.

He probably read Goldratt's follow-on to The Goal, Critical Chain. Critical Chain Project Management is the specific term. Goldratt tried to sell software to companies that would help them make schedules like that, but a large component (often ignored) was collecting historic data, and running models. Most companies might do one of those, but rarely both, and of course models with only speculative numbers are absolute garbage. In my experience, places that tried to apply CCPM never actually grokked it, and it was some manager's obsession because they were buzzword crazed (like many big-A Agile offices).

Re: Software effort estimation is mostly fake research

#73

I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.

I multiply by 4. Specifically, giving estimates on when features will be deployed/usable by end users.

Re: Software effort estimation is mostly fake research

#74
I had a conversation about estimates during a recent interview. I asked about how the company deals with those, and the interviewer said they don't do estimates because there's never been a time where something productive came out of one, and I think it makes sense.

In my experience, when an estimate is spot on the world goes on as if nothing happened. When it's incorrect, all hell breaks loose and it's every man for himself. And at the end of the day, all of the blame ends up on the person who guessed wrong. I'm glad I don't have to deal with that anymore.

Re: Software effort estimation is mostly fake research

#75
post #10

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

> It's engineering Numberwang.

Can I just say that is the greatest description of software estimation I have ever read? I am 100% stealing that.

Re: Software effort estimation is mostly fake research

#76
post #2

If 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…

Have you noticed their declining OS release quality in recent years? I have, and I now wait 6 months to upgrade.

The triangle is real[1]. Something's gotta give when a deadline can't move, and as we know from Brooks, software development speed doesn't increase linearly with more people. So it's primarily quality or scope that must suffer to hit a software deadline.

[1] - https://en.wikipedia.org/wiki/Project_management_triangle

Re: Software effort estimation is mostly fake research

#77
post #2

If 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…

I think it's because inexperienced programmers don't think about the "soft" costs of programming. Requirements gathering, general communication, testing, production rollout, coordination, research, final approval - it all adds up. For a 2 week project you might only actually spend a day of ass-in-seat coding. And that ass-in-seat coding is what they tend to estimate.

> I think it's because inexperienced programmers don't think about the "soft" costs of programming.

That's what the research has previously found[0] decades ago -- engineers will generally correctly estimate the part they are best at, but will either neglect or under-estimate other work. The old-school ways of dealing with this are canned Work Breakdown Structures and checklists.

This is not unique to software.

[0] van Genuchten, "Why is Software Late? An Empirical Study of Reasons For Delay in Software Development" https://web.archive.org/web/20160914040151/https://lab.cs.ru...

Re: Software effort estimation is mostly fake research

#78
post #2

If 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…

The principles behind the Manifesto for Agile Software Development mention only retrospectives, not estimates. You could say they value learning over guessing.

When people ask me how can they learn, I tell them to find old project schedules and other project documents. Looking at past projects makes the learning more objective, and it is not happening under time pressure.

Re: Software effort estimation is mostly fake research

#80
post #10

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

Yes. So you can more accurately estimate replicating components you’ve written before, eg another database client, but estimating new software is a successive sequence of uncertainty reduction. The first pass being highly intuitive, the second pass, with more of the details worked out, less so... until you’ve completed the first working version, and you can finally say in hindsight, it actually took this long.
Post reply on HN