Live data from Hacker News

Software effort estimation is mostly fake research

shape-of-code.coding-guidelines.com

61–70 of 318 posts

Re: Software effort estimation is mostly fake research

#61

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…

> but it probably took four times longer to make,

I doubt it. Luxury goods don't proportionately more cost much more to produce than commodity goods.

Instead they often derive their value from perceptions and exclusivity. That is people perceive the object to be more value for their own reasons, or they are made more expensive as a proof point of exclusivity / conspicuous consumption

https://en.wikipedia.org/wiki/Conspicuous_consumption

Re: Software effort estimation is mostly fake research

#62
post #14

Earlier quoted context omitted.

> "complete" means every single item the customer wants to see in the product, Ah, but the customer does not know everything they want, due to the fractal nature of reality. The closer you get to the end product, the more detail is resolved, and more work is added.

Although this sounds flippant, the design process is where unknowns should be uncovered. It is easier to change design before a line of code is written. Design is precisely what is needed in order for the dev team to break down the projects into tiny chunks where nothing is unknown. Your time estimates should always include time for research and design. The customer can sign off on what you're about to write at the e…

Yeah but too many customers change their mind even after they've signed off. Then you're left with strictly enforcing a contract or making adaptations.

You're right, design is very very necessary and should be given plenty of time. But it's not a magic bullet.

Re: Software effort estimation is mostly fake research

#63
post #33
post #25

Earlier quoted context omitted.

For one, it doesn't assume pace is consistent. Tracking velocity is part of the game too and it can vary with capacity, talent and maturity. Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.

Agree on the second point. I tried to convince some managers and sales guys to stop giving estimates at all and build trust otherwise, didn't work :) As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.

It is if you're following agile principles. By the time you've completed a few stories you should be delivering every feature at production quality with all the automation pipeline and deployments ready. The question from that point is always did we build enough features for a launch.

Re: Software effort estimation is mostly fake research

#64
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 do a fair bit of writing at work of various different types of things.

For stuff that I'm doing on my own? I can estimate pretty well. I know more or less how long the writing will take based on length. I'll allocate more time for research if I need to do more than a base amount. And then I add some slack in case I'm struggling with something, priority interrupts happen, or I'm just not into it on some given day. (Underpromise. Overdeliver.) It only gets harder with bigger projects. It helps that I'm quite fast compared to most people so even with significantly underpromising people are usually very happy with the estimate.

But where it's really hard is work that involves getting buy-in and input from a lot of different people. Those always take forever. (And at this point I pretty much know they'll take forever, a lot of which is just latency rather than actual active work.)

Re: Software effort estimation is mostly fake research

#65
Not only do we not know how to predict how long a software project will take, we don't even know how to predict what the end product will look like.

So who are we kidding?

Another way to look at it: take a small one-person project and assign it to three different developers. You may get wildly different results. How could you have predicted those differences in advance? Let alone apply that type of prediction across a large team.

About a dozen years ago I gave a presentation to the Silicon Valley Software Process Improvement Network (does it still exist?) My presentation: "Unsolved Problems of Software Maintenance." You think predicting greenfield development is difficult? Try predicting maintenance work, where figuring out what to do can be more than half the work.

Re: Software effort estimation is mostly fake research

#67

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…

My experience is that most customers are unwilling to wait for and pay for quality, especially if someone in the market sells a competing product (which itself is of low quality)

Re: Software effort estimation is mostly fake research

#69
post #55
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…

Very true, I think those estimates are actually two ideas/types crammed into one value. 1. The construction part, as you said, can be estimated. 2. I'd just call the other thing "allocated time" instead of "estimated time". Any time someone asks me how long it will take me to fix a bug that I haven't really looked at yet, or to plan some new feature or something like that, and they badly need a number, I ask them how…

This is brilliantly put. That's pretty much what engineering is – constraints and tradeoffs – giving software project planning/execution a healthy vocabulary to talk about makes it so much better. Much of the crappy feeling that developers go through by putting themselves into a corner can be avoided if everyone had better mental/language models to think/talk about it.

Re: Software effort estimation is mostly fake research

#70

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…

> but it probably took four times longer to make, I doubt it. Luxury goods don't proportionately more cost much more to produce than commodity goods. Instead they often derive their value from perceptions and exclusivity. That is people perceive the object to be more value for their own reasons, or they are made more expensive as a proof point of exclusivity / conspicuous consumption https://en.wikipedia.org/wiki/Con…

Mercades cars do often have more features, but I also am skeptical of claims that they are of higher quality.
Post reply on HN