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

171–180 of 239 posts

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

#171

Post by tonto »

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…

Also consider that the management or project is looking for just some vague white liquid and at the store you only see cans (powdered milk? Is that white?)

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

#172

Post by btbuildem »

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…

https://news.ycombinator.com/item?id=17235832

If you're really working on new problems all the time, consider yourself extremely lucky.

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

#173

Post by CamTin »

dredmorbius wrote: post #62
gonzo41 wrote: post #16

Earlier quoted context omitted.

Software is up there as the most complex thing ever created. People have been putting up houses for thousands of years, And modern big bridges for hundreds. Big software is ~40-60 years old. Its hard to have rules of thumb and best practice that will deliver the 'on time outcome'. Give it another 100 years. Most dev work right now is still just attempting to deliver correct software. let alone on time or on budget.

The Linux kernel is several times more complex than the Space shuttle. Order of magnitude as I recall.

Much harder to step the shuttle through a debugger though.

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

#174

Post by kareemm »

ItsMe000001 wrote: post #163
fvdessen wrote: post #25

Earlier quoted context omitted.

> The way to do this well is to break down a feature until they’re at about half-day sizes tasks. I have never seen that work in practice.

When I read that in OPs comment I immediately had to think of "How to draw an owl" (the meme version, not one of the serious online lessons -- https://pbs.twimg.com/media/DcC1YEyVQAA9Lkw.jpg ). "You simply break the task down into all its parts, then you just do it. Projects are easy." Not to mention that that approach only works if you produce another version of something you already produced many times. There certa…

> Planning well, finding out what to do, is harder than the actual programming. Again and again, in all projects, I find that the >90% part is finding out what to do. There

So you've advocating an approach where you... don't plan? I'm confused.

Perhaps you're getting too hung up on the half day part? That measure is a useful forcing function that ensures the dev team has thought through the approach in enough detail to identify where the risks are and what smart trade-offs can be made.

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

#175

Post by trey-jones »

williamdclt wrote: post #166
fvdessen wrote: post #25

Earlier quoted context omitted.

> The way to do this well is to break down a feature until they’re at about half-day sizes tasks. I have never seen that work in practice.

I'll go against all the other answers and say that I have seen that in practice. I'm even doing that in practice, every day of the week. A half-day task would even be a big task, most of our tickets are a couple hours maximum. We practice a lean-laced Scrum with 1-week sprints. And yes, it works. And yes, we go fast. So yes, it can work (thought we have several years of refining our methodology and have a big culture…

Do you mind putting out a number of hours (per dev team) that get spent in Backlog curation, story generation, and other budget planning every week? I think perhaps an important missing ingredient for getting budgets right is actually spending the time to do so. The smaller the company, the harder it seems to justify.

Indeed, for a lot of us in smaller companies, getting our clients to actually consider taking an agile approach at all is a stretch.

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

#176

Post by fjsolwmv »

crdoconnor wrote: post #72
bazooka_penguin wrote: post #21

Earlier quoted context omitted.

How do you estimate how much time a task will take, especially when it's a novel idea, at least for your developers?

Invest time in determining the right approach and planning it out. Most of that will be doing spikes: http://agiledictionary.com/209/spike/ It's one the most underappreciated agile concepts. I wish people would shut up about standups once in a while and give more thought to doing spikes.

It wouldn't be easier if we didn't have to keep learning silly new words for everything. I used to do prototypes and proofs of concept, now I have to do spikes.

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

#177

Post by ghettoimp »

wvenable wrote: post #140
notheguyouthink wrote: post #132

Earlier quoted context omitted.

> I’m kidding, of course. It really depends on how well business and development understand each other. Yup. This is the crux of the whole issue, and it's being completely blown out of proportion. There's always going to be details the estimator (dev) won't know, but the more clear a picture you have in your head, the more confidence you can have in an estimation. This is directly related to the size of the project t…

Estimates in software are effectively experienced guesses. This is in contrast to other industries, such as construction, where planning is done for months to ensure the estimate of time and materials is accurate. If you attempt to treat one as the other, you run into huge problems. Software isn't like building a bridge; it's like planning to build the bridge. I'm pretty good at software estimating; I can roughly tel…

Heh. But even in construction projects, serious cost/time overruns are very common. I can't find a good source through quick googling, but what I do find is horrifying.

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

#178

Post by fjsolwmv »

serpix wrote: post #79
hliyan wrote: post #44

Earlier quoted context omitted.

Well, they're just checkboxes inside the main tasks. You just think through how you're going to perform the task (which you'll anyway have to do when you get close to actually doing it), and note down the sequence of steps. Then you try to estimate each step. Sounds simple, but it works.

Why bother estimating? you have the checkboxes, now just get to work. If the pace of checking those boxes is slow then you can start cutting things out. Estimates are for managers, much better to just ship it already.

Because if you haven't built it yet, you can't ship it already.

But you are right that estimates are for managers. Managers should watch their reporter's progress and use that as evidence to build evidence. If the first task of 20 took 1 week, it's a 2year project. Update estimate as time and progress and work remaining increases.

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

#179

Post by fjsolwmv »

mkempe wrote: post #60
kareemm wrote: post #7

In my experience talking to hundreds of software engineering managers, running a software project management business, and being involved on software dev teams for 20+ years, there are two reasons why teams don’t ship or ship poor software. 1. Poor engineering planning. The way to do this well is to break down a feature until they’re at about half-day sizes tasks. Identify any obvious risks or ambiguities with the te…

In the context of a fixed-time, fixed-price/budget project it will fail to meet these constraints unless the scope is very clearly delineated at the outset, and ruthless scope/change management is applied throughout the progress of the project. And if at some point someone realizes that there was an omission in the scope definition, the time and budget must change. If the client or management want to change the scope…

Well sure, if you doom the project before you start, with a fixed price and scope, it will fail.

The original primary point of the Agile Manifesto is to stop doing that. There's no excuse for it, unless you are required by law as a government contractor, and in thar case no one expects a successful result anyway.

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

#180

Post by AstralStorm »

makmanalp wrote: post #135
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…

> you simply cannot know all the little details This is the reason big design up front hasn't been the gold standard in planning. Most modern methodologies acknowledge that there'll be a lot of changing requirements and learning-while-building. The point is, given this information, you could a) run around like crazy doing all manner of reckless and crazy cowboy programming and putting out fires b) carefully plan a re…

And then a poor maintenance programmer is faced will lack of architecture because the thing was built without any in mind... Just as a perpetual prototype.
Post reply on HN