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

Yes, Estimate Software Projects

blog.pragmaticengineer.com

Post reply on HN
Print view View original

71–80 of 96 posts

Re: Yes, Estimate Software Projects

#71

Post by spoondan »

cynusx wrote: post #58
jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

I think you are assuming that just because you estimated the work to be done that that would lead to a hard deadline on that day. In my experience hard deadlines are a bad idea but estimating work is also necessary to allow the organization to plan what to build. It also creates a beneficial cycle where stakeholders will reduce the feature set because typically smaller projects get front-loaded in the development roa…

I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response?

Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows they aren’t. NASA isn’t going to launch a vehicle that they know isn’t ready. Video games, hardware, and movies get delayed. Our software project can have features cut or the release date changed. And, for the most part, it’s okay.

That deadlines are “soft” in some sense doesn’t undercut any of the substantive points made against them, nor does it actually evidence any of the claims made for them.

Re: Yes, Estimate Software Projects

#72

Post by journalctl »

delusional wrote: post #19
journalctl wrote: post #3

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…

> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck What a sad way to view your profession. The requirements aren't hidden from you, and they don't just randomly change. You can't get them up front because no one has any idea what we are looking for. Solving a small problem usually reveals more of the problem. I don't thi…

It is sad, isn’t it? I wish it didn’t happen so frequently, and I wish my concerns weren’t dismissed so flippantly. How fortunate I am to have met someone who knows more about my situation than I do.

Re: Yes, Estimate Software Projects

#73

Post by barnaclejive »

> Why the sudden productivity change? We had a big deadline coming up, and there was no option of not shipping. Suddenly, the whole team became focused, distractions were all gone, and we moved at a faster pace than I've ever felt the team do so.

Uh, what? Sounds like at the end of the day you ended up busting your ass trying to meet some incorrect estimate. I was hoping to hear something about how making better estimates made your life better and didn't happen.

Re: Yes, Estimate Software Projects

#74

Post by cynusx »

spoondan wrote: post #71
cynusx wrote: post #58

Earlier quoted context omitted.

I think you are assuming that just because you estimated the work to be done that that would lead to a hard deadline on that day. In my experience hard deadlines are a bad idea but estimating work is also necessary to allow the organization to plan what to build. It also creates a beneficial cycle where stakeholders will reduce the feature set because typically smaller projects get front-loaded in the development roa…

I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response? Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows the…

My point is that there is a difference between giving an estimation of time and a commitment to deliver over a certain time. The parent assumes that just giving the estimate is the same as making the commitment.

The distinction between hard and soft deadlines is not relevant to my argument.

Re: Yes, Estimate Software Projects

#75

Post by username90 »

The advice to not give estimates is just to work around engineers bad soft skills. So if you have engineers who can keep a healthy relationship with stakeholders then estimates are not a problem, but if you have typical engineers then someone else will have to do the estimates for the engineers without consulting them. Ultimately someone has to do the estimates so if the engineers can't handle it someone else will be forced to.

Re: Yes, Estimate Software Projects

#77

Post by Haga »

journalctl wrote: post #3

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…

Agile is just the Ikea effect in action. Nobody blamed the chair- if he made it himself.

Re: Yes, Estimate Software Projects

#78

Post by bsder »

nilkn wrote: post #54
jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. Some folks tend to think that if a plan is produced but not followed exactly, then it wasn’t worth producing the plan. But actually having produced the…

> As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go.

I always despise these kinds of exercises.

We know how to roll up estimates correctly with statistics--even moreso if we have historical data.

The problem is that management always hates the accurate number.

And that's where the dysfunction sets in.

While everybody else rolls things up "normally", I almost always roll up an "accurate" timeline and try to inform people up front. It rarely wins me friends, but it sometimes protects my team when things are going haywire later.

Re: Yes, Estimate Software Projects

#79

Post by torgian »

Reading the comments ( and the article ) I think people are forgetting about the customer causing problems.

For example, what do you do when you and your customer agree on certain features by a certain timeframe and then... that customer turns around and promises something to someone else, then asks you if you can do that _without_ _consulting_ _you_ _first?_

If you refuse, you cause trouble for your customer, and potentially yourself. And then there's cultural considerations. And then your customer gets distracted by this and that, and you lose control of you customer?

This kind of thing happens. Plenty of companies are square in the "customer is always right" camp, which I think is a _bad_ idea. The customer is not always right.

This is why I think planning and estimating is a good thing, but controlling your customer is also important to keep in mind. You have to be willing to compromise, yes, but you also need to say "no" sometimes, or at least say "Well, let's finish this first, get the product out the door, and put that in version 1.5".

However, I feel like a lot of people are too scared to do that.

Re: Yes, Estimate Software Projects

#80

Post by learc83 »

torgian wrote: post #79

Reading the comments ( and the article ) I think people are forgetting about the customer causing problems. For example, what do you do when you and your customer agree on certain features by a certain timeframe and then... that customer turns around and promises something to someone else, then asks you if you can do that _without_ _consulting_ _you_ _first?_ If you refuse, you cause trouble for your customer, and po…

It's not just customers. The same thing happens with internal stakeholders. I've seen products where there is basically zero actual software design because development is driven entirely by short term feature requests.
Post reply on HN