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

Why software projects take longer than you think: a statistical model (2019)

erikbern.com

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Why software projects take longer than you think: a statistical model (2019)

#161

Post by ozim »

babyshake wrote: post #139
commandlinefan wrote: post #65

Earlier quoted context omitted.

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

If you are fully in charge of a project you can often create complete specs. When working with PMs, designers, other stakeholders, you can often not have complete specs because the requirements are constantly shifting. Because you're "lean" and "agile".

I don’t see this working out. Mostly people want something working right away and writing out specs would eat out all dev budget - you could create complete specs if you pay with your own money, maybe?

Re: Why software projects take longer than you think: a statistical model (2019)

#162

Post by QuercusMax »

darrylb42 wrote: post #112
commandlinefan wrote: post #65

Earlier quoted context omitted.

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.

Was the intention to force people to break tasks down into smaller chunks? There's no way you're spending months on something that can't be broken down at all.

Re: Why software projects take longer than you think: a statistical model (2019)

#163

Post by ozim »

HeyLaughingBoy wrote: post #120
rabuse wrote: post #113

Earlier quoted context omitted.

How so? Genuinely curious.

The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y. The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to somethi…

Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.

Re: Why software projects take longer than you think: a statistical model (2019)

#164

Post by ozim »

x86x87 wrote: post #110
jasongi wrote: post #71

Earlier quoted context omitted.

An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate. The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.

You do understand that an estimate is not a guarantee and should not be treated as one, correct? Planning poker is a sham. Between the abilities of variours sw engineers, their experience level and the knowledge in the area that needs to be touched almost any estimate can be given. In really it's just a way to create peer pressure and extract more value from people.

Some peer pressure can be good for the team/people.

Re: Why software projects take longer than you think: a statistical model (2019)

#165

Post by _ea1k »

TheCoelacanth wrote: post #146
_ea1k wrote: post #94

Earlier quoted context omitted.

Just wait until the Scaled "Agile" Framework[1] experts help to improve your efficiency with even more process overhead. [1] They weren't even concise with the acronym. Hey, lets throw a random e on the end!

Scaled Agile Framework is possibly the least agile thing anyone has ever done.

I completely agree. I've honestly been amazed at how many people are willing to advocate for it.

TBH, I'd have a lot more respect for it if the framework were sold honestly, as something completely opposite of agile. There's merit to a non-agile approach, but the dishonesty is something that I find very distasteful.

Re: Why software projects take longer than you think: a statistical model (2019)

#166

Post by Rury »

mmcgaha wrote: post #124
alentred wrote: post #45

Earlier quoted context omitted.

It depends on the company, or more specifically on how the company manages the budget (people working on projects, infrastructure budgets, etc.). In many companies people would rather do the other way around: inflate their estimates to make sure that they definitely fit the reality later. This also often leads to continuously increasing budgets because or the corporate logic: “if you asked for budget but didn't use,…

I have worked with both types of managers and many in between. My perception is that the sandbagger tends to be more accurate and executives tend to respect them more. The problem for the sandbagger comes when the project is large enough to get multiple estimates and the sandbagger gets put on the spot to explain his estimate. Our current project was estimated by our former VP at 4X and an outside consultant estimate…

The reason for this perception is because, if you claim it would take 4X, but you finish it in 1X, or 2X, or 3X, you can just pretend to be still working on BS things, and then viola you're finished at 4X. Otherwise, if you claim it when you actually finished, which was earlier then estimated, you look like a rockstar for having finished early.

Re: Why software projects take longer than you think: a statistical model (2019)

#167

Post by john_the_writer »

eschneider wrote: post #101
commandlinefan wrote: post #65

Earlier quoted context omitted.

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

It's realism, not cynicism. I've absolutely been in situations like that where the sensible estimate is 5X what management is angling for and I know it's the case because we've done that exact thing (In this case, new hardware bring up) many times and with the inevitable problems, it always takes the high number. :/

I worked at a place where everything had to be gold plated. Some devs had an idea for a json driven form. It was super simple. Less than a week of dev time. Management got it and an architect got involved. The project was taken from the original devs. The new team spent 2 months building a DSL, that didn't support mobile (so didn't meet the requirements). In the end it was canned.

The original 3 man dev team (Rails/JS/IOS) did a bit of skunk works, and built the original idea in 2 days. We had a good head of tech at the time so we deployed it and just kept quiet when we estimated new forms.

Re: Why software projects take longer than you think: a statistical model (2019)

#168

Post by john_the_writer »

I had one project where I estimated and gave a "project price" based on that. Mid way through (right after I wired up the payment provider) the client found out they were not approved to use that provider. So now I had to delete a weeks worth of code and start over.

After the change I sent a revised bill, and the client ghosted me.

Specs change, but people don't understand. If you have a wood framed house and mid way you decided it should be metal framing it changes the price.

Re: Why software projects take longer than you think: a statistical model (2019)

#169

Post by mikewarot »

It's my observation that the primary obstacle to software completion is specification and feature drift, not estimation.

The reason VB6 and Delphi for Windows were such great tools isn't because it eliminated the need for programmers, nor made programming that much faster... it's because those systems were comprehensible to domain experts, who could rig together something that actually worked, albeit in an unpolished and buggy state, skipping a cycle or two of prototype, requirements mismatch, adjustment, etc.

This gave the programmers an executable specification they could refactor and bug fix and polish up a bit. (And document.... you should always write good documentation)

Backstory:

My first major software project was writing an inspection system that utilized HP handheld computers, and I was able to crank out a prototype in about 2 months. The client didn't like the hardware (an HP box running basic with lots of "smart buttons"), and chose a different vendor to try again (after he did his own hardware testing and reviews)

My second major software project was the same system via the different vendor... and my estimate was about 2 months... it took 3 months (one week was away at Norand, the vendor of the new rugged handhelds, learning PL/N). There was a final month tweaking UI design, etc. and user testing. (Back in the days of MS-DOS, code in Turbo Pascal on the PC, and PL/N on the handheld) This included building a set of screen based editing libraries to allow forms based CRUD, customizing questions directly by the customer, the ability to flow through questions, etc. It was a greenfield project.

The client loved it, we met all the specs that were agreed upon, but it was totally unusable in practice. We made a deal to sell the system to 10 more locations, but would spend all the time required for me and the customer to work together and ruggedize/customize it for a better fit. That took a year. Everyone was happy, and it got integrated into some other products over time.

Then Windows and networks showed up, and the cost of handhelds fell like a stone. I moved into IT administration.

Re: Why software projects take longer than you think: a statistical model (2019)

#170

Post by przybytniewski »

Estimates != 100% project time spent.

I'd say the main issue is misunderstanding of concept we are planning between business and tech people. Those groups think so differentely. We use Planning Poker tool - https://scrumhub.it/ for each user story, but still there area projects unestimated with strongly extended timeline compared to initial estimates. But on the other hands mostly it happens when business add new features, change requirements and the wheel comes full circle, we do retro and it is what it is :)

Post reply on HN