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

Why Development Teams Struggle to Deliver on Time, on Budget, or at All

7pace.com

Post reply on HN
Print view View original

91–100 of 239 posts

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#91

Post by avmich »

jungturk wrote: post #81
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

> Development time estimation, and every methodology that attempts it (I'm looking at you, Scrum), are little more than desperate attempts by managers to feel in control and relevant. More charitably, they're an opportunity to introduce system 2 slow thinking on the team. There are certainly novel engineering problems that simply won't yield to estimation, but there are also lots of well-solved problems that will. Ma…

> but there are also lots of well-solved problems that will.

Certainly when you're writing a double-linked list a third time you can estimate how long will it take you. The problem is that in real life you never solve sufficiently the same well-solved problem. Feature details, matters of integration with other pieces of the system intervene - and in practice those errors introduced by new circumstances are significant comparing to predicted time. So the practice may be sound, but it doesn't give the desired results, like predictability of required time.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#92

Post by __dontom__ »

wildekek wrote: post #35

Higher up manager here. I fully accepted the #noestimates movement and it is a complete blessing for all the teams and organizations I've implemented it in. Roast me.

Did you do that in an agency as well? I mean it's one thing if you are developing a product, but telling your clients "the project is finished when it's finished and we won't be able to tell you how much it will cost you until it's finished" doesn't really fly in my experience.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#93

Post by brightball »

diego_moita wrote: post #84
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

A lot of people have been praising this "estimates based on data and rigorous planning" for decades. Steve McConnell wrote a whole book about it (Software Estimation: Demystifying the Black Art). It works only very special circumstances: when the task can be very well defined because it has been done a lot of times before and the people doing the task are very experienced on it. But the caveat is that if you are doin…

For what it's worth, the examples in that book are usually contract development shop where you're doing the same thing for multiple clients over and over.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#94

Post by dayvough »

true_religion wrote: post #45
chii wrote: post #5

Earlier quoted context omitted.

In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container…

Did you write this yourself? It's very good.

A quick google sent me here: https://funnyshit.com.au/the_plan.html

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#95

Post by chii »

true_religion wrote: post #45
chii wrote: post #5

Earlier quoted context omitted.

In the beginning was the Plan. And then came the Assumptions. And the Assumptions were without form. And darkness was upon the face of the Workers. And they spoke among themselves, saying, "It is a crock of shit, and it stinketh." And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof." And the Supervisors went unto their Managers, saying, "It is a container…

Did you write this yourself? It's very good.

No, it's an age old poem that was passed around on the internet. I happen to have kept a copy of it, but the authorship has been lost i m afraid.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#97

Post by Jtsummers »

Software is design, not construction. This is why it's hard to estimate.

You ask an architect to design a new skyscraper in a fixed three-month timeframe, good luck. It won't be what you want, or it'll have severe problems discovered during construction.

Software developers are creative workers, we have to accept this. Unless you're doing the nth iteration of basic CRUD/RESTful web app, or a trivial "display data from a database" app (note: the DB design may take more time, some of the controls on interaction will take more time, but the core of it will be the same) you can't reasonably estimate your time.

Once you know Ruby on Rails, making a prototype of a webapp is a rote task. You can knock it out in a known (from experience) time. Then you try to improve it, add new features, customize the backend (first time you've written a DB connector), things start going off schedule.

The only other way to have reasonable estimates of the development, is to spend a ton of time upfront (unestimable) designing the system before we touch the code. Ok, now the coding tasks are well understood, but you also just spent 2 years designing it. And, like the architect, if you rush this design part, problems will crop up during coding that will blow your schedule.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#98

Post by jbigelow76 »

Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work).

If you can plan and execute putting a person on the moon, you can plan and execute software development.

I think the problem is the overwhelming majority of software development is so low stakes, easy to replace, assumed that bugs are par for the course, etc... that most orgs have stopped putting real effort into planning AND executing on that planning, instead just cargo culting the planning phase.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#99

Post by Aaargh20318 »

notheguyouthink wrote: post #88
Aaargh20318 wrote: post #43

The reason that planning software development is bullshit is that you simply cannot know all the little details because in software development you're always doing something you've never done before (because if you did you could just copy-paste your previous work). To use the 'going to the supermarket for milk' example. I could make a fairly accurate estimate for that because I've gone to the supermarket hundreds of…

This is being a little extremist, no? I'm consistently asked to give estimates, and I mostly give estimates that are accurate within sane expectations. I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I c…

> I think what's missing here is that I can predict how long something is going to take when I talk with the managers/feature-planners about what the feature is. If I feel I have a solid understanding of the requirements, which pieces of code it'll touch, etc - then I can give a reasonable estimate.

I'd argue you can't.

Right now I'm working on a feature that I estimated as 'a couple of hours'. I've been working on it all day by now. Not because the feature is that difficult, or because I didn't get a set of good requirements. The requirements are crystal clear and should be easy to implement.

The reason it's taking so long is that I'm fighting with a UI component that doesn't behave as expected (or documented). What should have been a trivial part of this task, a matter of seconds and not worth estimating at all, turns out to take all day because I didn't know this specific component is misbehaving and I couldn't have known until I started implementing it.

You cannot predict things like that without doing it.

Re: Why Development Teams Struggle to Deliver on Time, on Budget, or at All

#100

Post by sonnyblarney »

icebraining wrote: post #89
sonnyblarney wrote: post #61

Earlier quoted context omitted.

I have to respectfully disagree with #1. Software is hard because we 'don't know the unknowns'. It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. If we knew how to write the module, we'd just do it, test it, and voila. But most of our time is spent 'figuring stuff out'. Oh, product has asked for a tiny change (support a specific…

It's not like building a building - if it were, we could just schedule it down to each detail. We would be still all be using 'waterfall'. I hear that it doesn't work that well for buildings either, as you end up with people in the field detecting bugs in the plans and having to improvise fixes without input from the designers.

For actual buildings, they spend a fortune up front planning.

Soil and dirt samples at $100K - just to do a bid on a project, let alone the actual build.

Can't spend $500M on something only to find you have to tear it down.

Software is not magic, but it does require thoughtfulness and experience ... (hint to all those who think startups require mostly new/young blood - it's mostly wrong, but that's for another post)

Post reply on HN