Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Estimation Games

thomsett.com.au

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Software Estimation Games

#21

Post by asgard1024 »

georgeecollins wrote: post #9

"...It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process..." If there was a planning process that was consistently reliable for new, complex software I think people would use it. And I think the adoption of agile methodologies in software development is an example of people trying…

> If there was a planning process that was consistently reliable for new, complex software I think people would use it. And I think the adoption of agile methodologies in software development is an example of people trying to implement an improved planning process.

There are such processes. But they require understanding of the problem, which takes time. I am not sure "agile" is really attempt at an improved planning process, it's at best not doing planning and just marching onto the problem, seeing what happens at regular intervals in the hope of better understanding it, and at worst, things like "planning poker" where you put a bunch of people into a room and let everybody make a (possibly educated but usually not very much) guess from the top of their heads.

Re: Software Estimation Games

#22

Post by pnathan »

I had many long discussions with a previous boss about estimates. What it boiled down to is this:

* He is on the hook for certain things to be done, and is being asked when they will be done.

* I don't have enough data to tell him in such a way that the organization can plan around it. Anything I tell him is purest moonshine and unicorn hair. Sometimes it relates to reality.

* If I give an estimate, I am essentially passing dishonesty through the organization. I am lying to him.

This did not go over well. We compromised: I gave a order of magnitude WAG. Which, at the least, gives meaningful information and probably isn't wrong.

Re: Software Estimation Games

#23

Post by vermooten »

I'm a development manager and so am obviously asked to give estimates all the time. I found many years ago that no-one reads the qualifications that go with estimates, they just want a date or a number of weeks' effort and assume that it's a commitment.

I now play The Quality Game, which works every time. An example from a few weeks ago:

I gave an estimate for a piece of work which has plenty of contingency. For any number of reasons, when I gave the date, I expected a sharp intake of breath from the client --- so I quickly added: "The reason for this is that it's a complex piece of work - I've allocated 2 developers and one DBA for 6 weeks, and then one tester for 4 weeks. It's complex and important, and there is no way that the team wants to compromise on quality. That's why it's taking so long. Obviously, if we can do it faster, we will. How does that sound?" No problem.

I've played the Quality Game when telling clients that they need to upgrade to a later version, despite their having been told they wouldn't have to. Upgrading takes time and effort. Again, when quality is at the center of what you do, the logic is unassailable. ("WE could do it without you upgrading - of course - but our strong recommendation is that you upgrade. We're not saying this to piss you off, we're saying it because we want you to have the best quality product possible.").

Dev teams and clients never want to compromise on quality. Sales people don't care, they have to hit their figures, but it's 2 against 1. We win.

Thing is: it's not a game, it's just the truth.

(Great article BTW, will share with colleagues!)

Re: Software Estimation Games

#24

Post by john_b »

jt2190 wrote: post #18
rainmaking wrote: post #7

This is a nice taxonomy of estimation games, but stopping the games won't address the root problem: Software development is complex enough to be fundamentally unpredictable. The games are just about hedging against people not wanting to hear that.

> Software development is complex enough to be > fundamentally unpredictable. This is false. The weather is an extremely complex system, yet we use weather forecasts all the time. What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future. ("Maybe I'll carry an umbrella today.") The equities market is an…

> "What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future."

Weather is governed by impersonal physical forces which can be described by mathematics. Software is built by groups of people who most defitely cannot be modeled as mathematical entities. Weather is a bad analogy here.

> "The equities market is an extremely complex system, yet we use market forecasts all the time. What's different between equities market and software is that everyone knows that equities market is extremely complex, and we account for that when we think about the price of an equity in the future. ("Maybe I'll diversify my investments.")"

Those market foreasts are often wrong. Even a company's own forecasts are frequently wrong, despite having the optimal perspective from which to make those forecasts.

Furthermore, diversifying investments is easy to do because the price mechanism makes those investments fungible (in a liquid market, anyway). This is not the case with software. Each piece of software is unique. You may "diversify" your software by investing in multiple projects, but ultimately you have a business need for a piece of software which does task X. "Diversifying" by funding software that does tasks Y and Z will not help you if the software "investment" in task X fails. "Diversifying" in three software projects, all intended to do task X, will roughly triple your costs for doing X. Again, equities are a bad analogy.

Software development is a process which can't be easily summarized by analogies to existing systems. In fact, the term "software development" can describe many different systems.

The real reason schedule estimation in software development is so hard is because, regardless of which system of software development is used, the problem of simultaneously optimizing to maximise a desired quality while minimizing the cost/schedule is inherently hard in a mathematical sense. Changes which promote one oppose the other, and the sensitivity of a software development system to unknown and unpredictable future changes cannot, obviously, be predicted in advance.

Your point about hedging one's bets is valid, but there are costs to doing so which are not as simple as carrying an umbrella or splitting up a pile of money across multiple equities.

Re: Software Estimation Games

#25

Post by davegauer »

michaelochurch wrote: post #12

This is an excellent article. It's a great synopsis of what's really behind those estimates, whether in naked form or couched in that "story points" bullshit of the "Agile" cult. I fucking hate all of it. Here's my take. Programmers don't underestimate because they're afraid of getting fired or yelled at. In this market, a good developer is unlikely to be fired for honestly estimating. Yelled at, yes. Fired in worse…

I assume you were down-voted for going on a tear about Agile methods. I can't speak to that since I've never been in an Agile shop (read about it plenty).

But I think what you have written is applicable to most developers in general, particularly this gem, which I loved:

    "The thing that motivates us is delivering a
    major project that gives us enough credibility 
    that we never have to make estimates again..."
I also agree that the article was wonderful. I laughed out loud several times because, like all of the best comedic material, it is firmly grounded in the painful truth.

In the end, developers really do just want to build great stuff and I think most of us _are_ acutely aware of the realities of costs and time in real business. I sympathize with management's desire for estimates (and even the various methods to somehow get a reign on development). But the unfortunate truth is that the attempts often only serve to irritate and chain down people whose only desire was to work like hell making quality software in the first place.

Re: Software Estimation Games

#26

Post by jt2190 »

john_b wrote: post #24
jt2190 wrote: post #18

Earlier quoted context omitted.

> Software development is complex enough to be > fundamentally unpredictable. This is false. The weather is an extremely complex system, yet we use weather forecasts all the time. What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future. ("Maybe I'll carry an umbrella today.") The equities market is an…

> "What's different between weather and software is that everyone knows that weather is extremely complex, and we account for that when we think about the weather in the future." Weather is governed by impersonal physical forces which can be described by mathematics. Software is built by groups of people who most defitely cannot be modeled as mathematical entities. Weather is a bad analogy here. > "The equities marke…

  > Software is built by groups of people who most defitely 
  > cannot be modeled as mathematical entities.
Putting aside whether mathematics is up to modeling human behavior, why does a project schedule estimate need to be modeled using people?

  > Weather is a bad analogy here.
I was using weather as an example of complex things that can be estimated, not as an analogy for software development itself. Sorry if I wasn't clear about this.

  > Those market forecasts are often wrong.
Useful forecasts/estimates are seldom binary, and "wrong" versus "right" is a bad way to evaluate their usefulness. Estimates have both precision and accuracy. For example if you want perfect precision (as in the wrong/right example), you may in turn get a very low accuracy, i.e. the estimate will often be incorrect. If, on the other hand, you can live with less precision, you can often get higher accuracy.

  > The real reason schedule estimation in software 
  > development is so hard is because, regardless of which 
  > system of software development is used, the problem of 
  > simultaneously optimizing to maximise a desired quality 
  > while minimizing the cost/schedule is inherently hard in 
  > a mathematical sense. Changes which promote one oppose 
  > the other, and the sensitivity of a software development 
  > system to unknown and unpredictable future changes 
  > cannot, obviously, be predicted in advance.
Again, this is true only if you need very high precision and very high accuracy. If you can live with lower accuracy and precision, estimation becomes quicker, easier and cheaper.

So I stand by my original assertion that software estimation is not impossible.

(edit: To remain consistent, I should say that software schedules are certainly predictable, just not perfectly predictable. Most teams can get by just fine with good enough predictions.)

Re: Software Estimation Games

#27

Post by ThrustVectoring »

A game I play that is not mentioned in the article: give an estimate in the form of "I will not be done with this before %time." I'll often add in something about giving a better time estimate for the entire thing when that period of time elapses.

I usually build that time estimate by imagining the whole process going smoothly. The vast majority of surprises are negative, and of unknown size, so however long the project takes, it's going to be something bigger than the everything-goes-right scenario.

Post reply on HN