Why Development Teams Struggle to Deliver on Time, on Budget, or at All • Hacker News Board

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

#151

Post by nradov » Tue, Jun 05, 2018, 5:34 PM UTC

jillesvangurp wrote: post #129

There's a lot of snake oil for sale if you are looking to spend money on solving this problem; this probably is more of that. The reality is that mostly we've gotten better at avoiding things that clearly don't work or are historically obviously misguided/inappropriately expensive (waterfall, CMM level 5, etc); and instead emphasizing things that don't work slightly better: managing risk by doing iterations, not atte…

CMM level 5 does work, if you actually do it instead of just treating it as a paperwork exercise to satisfy an auditor. There's nothing in CMM that's contrary to or incompatible with Scrum or other agile methodologies. The major emphasis in CMM is on documenting your process (whatever that process is), training people properly, and continuously improving.

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

#152

Post by debt » Tue, Jun 05, 2018, 5:34 PM UTC

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…

Massive software companies deliver high-quality software, on-time all the time for one reason: resources. They got the money and the time and the developers and all the enterprise accounts up the wazoo.

Typically no one wants to pay more for less, but that's the best strategy to deliver high-quality software on time.

You reduce the scope drastically but do not adjust the timelines. You pay for more development resources(tooling, developers, servers, time, etc.).

If you can't deliver at that point, then there's a serious fundamental issue with either the leadership or the team or both.

Startups don't have this luxury. So they must execute on the least complex scope on a very tight timeline. High-complexity scope increases the fatality risk to the company.

So as the scope increases in complexity the risk increases and the likely the company itself will fail increases. Again, because startups do not have the cash to pay for the proper amount of resources.

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

#153

Post by nradov » Tue, Jun 05, 2018, 5:37 PM UTC

thinkingemote wrote: post #52

One statistic that has stuck with me is that 80% of software projects fail. It's the default that your software will not succeed, or do well. One small reason for that is poor time estimation, but having good time estimation won't make your software succeed. I think having good planning, makes for a good working environment, but it doesn't mean the project as a whole will succeed. It might mean the developers will be…

That's a meaningless statistic. The vast majority of large software projects do eventually deliver something of value, even if it's late, missing features, and full of defects. Is that a failure? Depends on the circumstances.

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

#154

Post by AnimalMuppet » Tue, Jun 05, 2018, 5:42 PM UTC

I kind of like the XP approach to this.

First, estimates longer than two (or was it three?) weeks need to be split into smaller pieces. (Because it seems that when the estimates exceed two weeks, the accuracy of the estimates goes down. We're just not good at estimating things longer than that.)

Second, if you don't know enough to make the estimate - if the task is something that you don't know how to do - the first task is to find out. In XP, this is called a "spike" - a task where the purpose is to nail something down, rather than to produce a usable artifact. Often you don't know how to do something, but you can say that after two weeks of research, you'd have a better idea. So take the two weeks of research, and then you can give a decent estimate. (Hopefully - there are some tasks that you'll know you're done when you're done.)

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

#155

Post by Animats » Tue, Jun 05, 2018, 5:57 PM UTC

Development time estimates are too short because there's no penalty for management underestimation. If programmers were paid like the movie industry, estimation would be more reliable. Time and a half after 8 hours, or after 5 days. Pay for 4 hours if you're needed briefly during off hours. Double time on Sundays. It's not just telling people it's a "crunch".

Movie scheduling and estimation is organized enough that you can buy a completion bond. If the job isn't completed within an error margin over cost and schedule, the completion bond company pays. If there's a cost overrun, the completion bond company has the authority to send in their own people to monitor things and if necessary, to fire the director or anybody else, and take over the production.[1][2]

Completion bond companies do project cost and schedule estimation independently of the production. They have the data for this, because they have the full accounting data for hundreds or thousands of films. They watch project progress carefully. "Our monitoring process requires the production to email us daily shooting progress reports and a weekly cost report in order to properly evaluate the progress of the film. FFI also makes periodic visits to the shooting area."

This prevents directors and producers from low-balling their estimates. Underestimation leads to unemployment.

A completion bond typically costs about 4% of the film budget.

[1] https://www.eqgroup.com/completion_bond/ [2] http://www.filmfinances.com/services/evaluation

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

#156

Post by Jtsummers » Tue, Jun 05, 2018, 6:06 PM UTC

nradov wrote: post #150

Jtsummers wrote: post #97

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

Architects regularly design new skyscrapers on fixed schedules. Look at some of the major developments going up in China.

How many of those fixed schedule projects are based on old and proven designs? I specifically emphasized new in that sentence. Perhaps I should have said to produce novel designs. Which is what many programmers are asked to do and estimate.

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

#157

Post by fokinsean » Tue, Jun 05, 2018, 6:10 PM UTC

mirceal wrote: post #27

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…

Have you ever been in a situation where communicating and breaking things down takes longer than the actual work? IMHO most disasters I’ve seen occur when ‘Product’ tries to strictly control the ‘Developers’. It just does not work for certain kinds of projects. It also diminishes the developers’ involvment and leads to a culture of mediocrity and CYAs. Also, a person that does not have to do the work will always be w…

> Product trusts Dev on implementation

Currently having issues with this one right now, and it is the most frustrating thing I've experienced at a job.

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

#158

Post by cpeterso » Tue, Jun 05, 2018, 6:13 PM UTC

jcadam wrote: post #66

golergka wrote: post #14

> This is where System 2 comes in—if we performed a more thorough analysis, these factors would have been considered in our answer. Then it would be clear that it’s much more likely to take 20 or 30 minutes to run to the store instead of 10. I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correla…

> I have encountered an article (can't find the link now, sadly) that claimed that when developers gave estimations, breaking down tasks to sub-tasks actually had a reverse correlation to their accuracy. In other words, their first gut reactions were actually better than estimations given after going in-depth through all the details and sub-tasks. I've noticed this as well. The last few years my 'gut' estimates have…

Bottom-up estimation is probably more accurate for the work to be done, but not for other project overhead. Using data from an analogous project to forecast the delivery date would include that overhead.

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

#159

Post by s73v3r_ » Tue, Jun 05, 2018, 6:17 PM UTC

chiefalchemist wrote: post #101

If you __really__ don't get to set the deadline, is it still reasonable to held accountable for that miss? Even if you give worst case and best case the only one anyone else focuses on it best case. Personally, I prefer the 80/20 rule. That is most of the work will go fair quickly, or at least uneventful. It's the last bit that's always the killer. The devil is in the details, as they say. When asked for an estimate…

"If you __really__ don't get to set the deadline, is it still reasonable to held accountable for that miss?"

Not at all, but unreasonableness has never stopped management before.

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

#160

Post by house9-2 » Tue, Jun 05, 2018, 6:18 PM UTC

ttul wrote: post #11

jhall1468 wrote: post #3

In my experience, deadlines set by higher-ups long removed from (or never having) the technical chops to be determining the deadlines in the first place. VP's and Directors are often the ones dictating the direction, which is great, but then also introducing deadlines, with helpful input from Directors who ALSO haven't touched code in many years. Generally that results in one of two things: * Product delivered on-tim…

Having worked in the trenches as a software engineer and also as a CEO has given me respect for the VP level as well as the engineers. When the VP sets a deadline, it’s driven by the survival of the company - aka release by June or we can’t make our numbers and have to do layoffs. When the engineers push back, they often do so without an appreciation of the business reality, aka those numbers pay their salaries. Engi…

> When the VP sets a deadline, it’s driven by the survival of the company

Sometimes...

Other times its driven by the fact they are personally going to get a fat bonus