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

81–90 of 96 posts

Re: Yes, Estimate Software Projects

#81

Post by yibg »

alecbenzer wrote: post #51

I'm intuitively on team #noestimates but trying to have an open mind/not dig in my heels. I feel like no one does a convincing job at communicating why estimates matter (and how much value you get out of how precise of an estimate). Fundamentally, an estimate (or any piece of information) is really only of value if you're going to do different things based on learning it. E.g., given an estimate, you might: * Priorit…

One reason for rough estimates is for making investment decisions. If we have 10 things to do but can’t do them all how do we choose which to do? The what the thing does points to the return piece but we’d need the investment piece too to evaluate which ones are better value.

Re: Yes, Estimate Software Projects

#82

Post by agentultra »

Do it if you want but in all my years I've never seen a company sunk by a missed deadline. At best it's a minor set back. At worst checks get delayed or contracts terminated. Maybe that's enough to sink your tiny startup when you're first starting out. For most companies that have made it past their first year it's not the end of the world.

Empirical studies on the causes of errors, delays, etc in software projects of different stripes and knowledge work in general suggest that stress and sleep are the most important factors [0]. In video games deadlines are paramount and yet, ironically, crunch as the systemic form of over-work has become known correlates strongly with review scores and sales: the more a team is forced into meeting these arbitrary deadlines the lower the review scores and overall sales of the game [1]. I don't think this is unique to the games industry. I've seen enterprise development shops put in crunch time to meet customer driven deadlines agreed to by the sales teams with similar results: developers burn out and leave the company, tech debt runs rampant, and customers get frustrated.

The article doesn't touch on the different kinds of projects one may be asked to give estimates for.

A speculative project shouldn't be estimated. This is where the team doesn't have the skills required or has never shipped any software with a similar scope or feature set. There are so many unknowns between where you are and the end goal that an estimate is only a dangerous guess. The only way you can make an accurate estimate is to begin work and get close to the goal. Some where between starting and finishing you will have enough information to make an informed and reasonably confident estimate. Along with good release planning this can be a relatively low-stress process. Estimates at the beginning of the project create poor expectations and can lead to stress.

The enemy of a good plan is a perfect one.

Stress is so bad that it won't matter, much, that you do code review or have automated CI and CD gates and checks. Your engineering team will simply not be as effective as a team that isn't stressed or tired. Anything you can do to keep your team from being stressed out or tired is going to translate into better outcomes. If that means relaxing on deadlines and focus more on results and progress than do that instead.

One thing I can agree with is that communication is key. And a good night's sleep.

[0] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2656292/

[1] https://gamasutra.com/blogs/PaulTozour/20150120/234443/The_G...

Re: Yes, Estimate Software Projects

#83

Post by alecbenzer »

yibg wrote: post #81
alecbenzer wrote: post #51

I'm intuitively on team #noestimates but trying to have an open mind/not dig in my heels. I feel like no one does a convincing job at communicating why estimates matter (and how much value you get out of how precise of an estimate). Fundamentally, an estimate (or any piece of information) is really only of value if you're going to do different things based on learning it. E.g., given an estimate, you might: * Priorit…

One reason for rough estimates is for making investment decisions. If we have 10 things to do but can’t do them all how do we choose which to do? The what the thing does points to the return piece but we’d need the investment piece too to evaluate which ones are better value.

For sure, that's what I meant by the ROI bullet.

I just often feel like people want estimates that go beyond the level of precision/accuracy you'd need to make a relative ROI call. And just in general don't do a good job motivating _why_ they want the estimate.

Re: Yes, Estimate Software Projects

#85

Post by shiningdays »

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…

Yes this!!

Re: Yes, Estimate Software Projects

#86

Post by xtracto »

pjc50 wrote: post #61
nilkn wrote: post #54

Earlier quoted context omitted.

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…

This is Eisenhower's "plans are useless but plans are vital"

There is another saying in modeling and simulation: All models are wrong, some are useful.

As an Eng. Leader I use planning and estimates to communicate with other stakeholders.

One thing the majority of people fail at is giving variance when providing a forecast/estimate.

If someone asks me to get an quick estimate for developing something I'll give them a range with wide margin, around the avg time I think it will take. If they want to reduce that range, then I need info to understand the requirements better.

Problem has always been that what engineers provide as an ESTIMATE, business takes as a deadline. So, engineers: always add buffer to your estimate.

Re: Yes, Estimate Software Projects

#87

Post by knightofmars »

bsder wrote: post #78
nilkn wrote: post #54

Earlier quoted context omitted.

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

A co-worker and I were asked to write up an estimate for a new project. We sat down, walked through the components (best we could at the time) and came up with an estimate (which was likely smaller than the actual given the unknowns). We provided the estimate to leadership. They decided not to do the project. Next, I hear from the head of engineering, "You can't go giving huge estimates to leadership. It makes us look bad." It was one of those moments that reinforced my belief that the "image game" and reality are in conflict and people who enable the "image game" are one of the biggest problems in software estimation.

Re: Yes, Estimate Software Projects

#88

Post by [deleted] »

knightofmars wrote: post #87
bsder wrote: post #78

Earlier quoted context omitted.

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

A co-worker and I were asked to write up an estimate for a new project. We sat down, walked through the components (best we could at the time) and came up with an estimate (which was likely smaller than the actual given the unknowns). We provided the estimate to leadership. They decided not to do the project. Next, I hear from the head of engineering, "You can't go giving huge estimates to leadership. It makes us loo…

[deleted]

Re: Yes, Estimate Software Projects

#89

Post by Too »

davidjnelson wrote: post #41
Osiris wrote: post #11

My current employer switched from SCRUM to KANBAN. We're broken up into person squads. Epics are created by product by engineers are involved in kickoff and story breakdown. We use KANBAN cycle times to estimate delivery dates. For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date. It…

Interesting. Who made the decision to switch and who pitched it to execs? In my experience an executive is the only one who can make this decision. Extremely curious how this worked out.

It should be up to the team to decide the process that works best for them. FWIW that's what agile manifesto says also. Agile is not equal to scrum btw.

Re: Yes, Estimate Software Projects

#90

Post by timwaagh »

I am glad it works for you but I am not comfortable or confident doing this, unless i have a really firm grasp on the technology and that is the exception rather than the norm, these days. Estimations tend to be driven by customer expectations rather than technical limitations. If i estimate too high I look bad. Even if that is based on previous experience. If i don't deliver in the hoped-for-timeframe i might get fired. catch-22. Much better to not do it at all, if the business allows it (if it doesn't then it's still important to make keep hammering on estimation psychology ).
Post reply on HN