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

31–40 of 96 posts

Re: Yes, Estimate Software Projects

#31

Post by shaggyfrog »

UK-Al05 wrote: post #23
klenwell wrote: post #5

I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt. In Thinking Fast and Slow, Daniel Kahneman offe…

In many ways the story points are outside view. You estimate complexity, then you look at how long it took to do stories of simular complexity before.

In theory.

In practice,

- stories are not always the same "size",

- someone correlates story points to a time unit,

- everyone estimates stories differently,

- not everyone understands how to do the thing because they've never done the thing,

- everyone understands complexity differently,

- people makes estimates to what they think everyone else will say,

- no one ever goes back and updates an estimate,

- the estimates are never used as data in the future,

- there are never enough estimates to create a reasonable model that gives predictability better than a hand-waving human,

- no one's really invested in the estimates they are giving., because no one really cares that much except for whoever "needs" the estimate,

- estimating meetings are incredibly boring and a waste of time,

- they give everyone a false sense of certainty

I'll stop there...

Re: Yes, Estimate Software Projects

#32

Post by ThalesX »

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…

What a sad way to hammer someone’s view of his profession based on a comment.

> You can’t get them up front because no one has any idea what we are looking for.

Is this requirement implementation or R&D?

While it’s understandable for R&D to be exist within the ‘no one has any idea what we are looking for’, to fit all software development into this paradigm is to have a pretty lax understanding of how most software operates...

> Solving a small problem usually reveals more of the problem

This is exactly what I think the parent post was arguing when shying away from estimates.

Re: Yes, Estimate Software Projects

#33

Post by temac »

pinkfoot wrote: post #15

> 100 plus people to port Skype in 16 months. To all employers out there: if you put me on a project with a hundred others to port a wee VOIP front-end to another platform, I too can get it done in a year and a half.

I don't know Skype but it can be easy to understate the scope of some programs.

Like a web browser: why do we need that crap to be that large and complicated again?

And that's a valid question (be it about voip software or web browser or pretty much anything), but even then it is still naive to pretend complexity (whatever its origin and justification) does not exist and everything could and should be completely rewritten in 3 weekends by 2 interns.

So: why don't you just go work at MS and see by yourself? Seems like they have some kind of ideal conditions in your opinion.

Re: Yes, Estimate Software Projects

#34

Post by awinter-py »

shmundada wrote: post #26
awinter-py wrote: post #2

This is such an important topic and missing skill in the tech workplace. It's impossible to prioritize work without estimating the cost & value of projects, and teams that don't prioritize are always overworked, playing catchup and are unhappy. What the author says about 'we shipped different functionality to what we planned' is really important too -- beginning managers aren't willing to have this conversation but s…

> make time to identify & resolve unknowns before committing to features / timelines. I find it difficult to identify unknowns before I actually start working on it. Personally it makes sense to just give it a go as estimating it correctly may be as time consuming as completing it. Especially true for one off feature or bugs in large codebase.

That's fine for smaller chunks of work, and you're right that resolving uncertainty is not cheap.

But if you're doing resource planning for a large organization and you need to decide between high-value, long-timeline projects, that decision is irresponsible without some homework up front to validate the timelines.

Large projects involve high- and low-uncertainty work and it's useful to do some of the former before spending resources on the latter.

Your estimate still won't be right, probably, but the chance of uncovering an important problem is worth it.

Re: Yes, Estimate Software Projects

#35

Post by davidjnelson »

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

Yikes, too true!

What about confidence intervals? I’ve found that’s a solution that makes the most people the least unhappy.

Re: Yes, Estimate Software Projects

#36

Post by pas »

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…

No estimation without experience.

This works. New team? Needs time to get average velocity (burn down rate), about a month.

Greenfield project? Need time to figure out how complex the domain is, again at least month, maybe two.

Sure, you can still have deadlines, but keeping them without real data to base estimates on will require feature cuts (or more resources, but by the time it becomes clear it's too late).

Re: Yes, Estimate Software Projects

#37

Post by davidjnelson »

mikewhy wrote: post #14
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…

I really, really like Kanban as well. Seems the hardest part is selling it to upper management.

Because they want hard deadlines. I don’t think this is something that can be “fixed”. I think it’s something you discover in an interview and use as a make or break join/pass decision if you truly care about it.

Re: Yes, Estimate Software Projects

#38

Post by milesvp »

dllthomas wrote: post #21

I think estimates of effort required, estimates of timeline, and commitments to timeline (deadlines) are three different things with only loose relationships that are far too often conflated - to significant pain. I'm trying to play with this a bit in my personal process (and talking to my team about it) but don't really have any hard results yet.

Very much this. I try to never give an estimate without giving 2 values. The expected effort, and the expected calendar time. Sometimes I’ll also add expected complexity since that adds a lot of risk to both estimates. There are lots of things I’ve done that were quite easy, then I spend lots of time just sheparding the feature into production. Especially if you’re working with other teams, or vendors, and can expect 24hr delays for every email round trip.

In fact each department or vendor involved in a project will easily double calendar date, and often complexity as well. At a previous job we automatically increased our t-shirt size for every vendor just to keep our estimates honest. And there was only like one vendor who we would make exceptions for since they were always amazing to work with.

Re: Yes, Estimate Software Projects

#39

Post by pinkfoot »

temac wrote: post #33
pinkfoot wrote: post #15

> 100 plus people to port Skype in 16 months. To all employers out there: if you put me on a project with a hundred others to port a wee VOIP front-end to another platform, I too can get it done in a year and a half.

I don't know Skype but it can be easy to understate the scope of some programs. Like a web browser: why do we need that crap to be that large and complicated again? And that's a valid question (be it about voip software or web browser or pretty much anything), but even then it is still naive to pretend complexity (whatever its origin and justification) does not exist and everything could and should be completely rewr…

You missed the, admittedly subtle, point of my post.

Re: Yes, Estimate Software Projects

#40

Post by davidjnelson »

klenwell wrote: post #5

I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt. In Thinking Fast and Slow, Daniel Kahneman offe…

> If your deadline is fixed, be ready to scale back.

True. Honestly, what else can you do if a deadline is approaching than to cut scope? Even enforced death marches aren’t necessarily going to solve it...

Post reply on HN