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

101–110 of 178 posts

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

#101

Post by eschneider »

commandlinefan wrote: post #65
bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

> 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. :/

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

#102

Post by ep103 »

Tade0 wrote: post #86
sideproject wrote: post #26

I'm genuinely looking for a "calm" company. Is there such a thing? I have a few anecdotal stories of companies being absolutely chaotic (my current one included). I don't know where to point fingers to. I could start at pointing myself. Customers demanding custom features. Execs and sales people asking for unreasonable estimates. Engineers not feeling safe enough to say "no" but have to make something work, introduci…

> I'm genuinely looking for a "calm" company. I'm contracted to the IT branch of a certain pharma company and it's been calm the whole time. Projects are either about regulatory compliance (boring, but not challenging) or supporting research - the big brains do the thinking, while you just klaka klaka klaka away at the implementation. A visible chunk of the latter goes nowhere and eventually gets cancelled, but every…

The more insulated you are from sales / overhead cost reduction pressure, the calmer things will be. Just make sure you're insulated, not so far that you're seen as a cost center as opposed to a revenue generator

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

#103

Post by AssertErNullNPE »

Management: We've got a great new project that has all the features that our users have been asking for. We need it done as fast possible, it's the number one priority. How fast can we get it done?

Engineers: For all of it? At least a year, probably more. Even a subset of those features will take six months, minimum.

Management: That's too long. You can have all the resources you want, we need to have it done in 90 days.

Engineers: That cannot be done. No amount of effort or engineers will get it done in 90 days.

Management: It will be done in 90 days.

180 days later

Management: Why are so many of our projects late?

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

#104

Post by moffkalast »

commandlinefan wrote: post #65
bonoboTP wrote: post #23

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…

> 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 is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

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

#106

Post by Fourier864 »

sideproject wrote: post #26

I'm genuinely looking for a "calm" company. Is there such a thing? I have a few anecdotal stories of companies being absolutely chaotic (my current one included). I don't know where to point fingers to. I could start at pointing myself. Customers demanding custom features. Execs and sales people asking for unreasonable estimates. Engineers not feeling safe enough to say "no" but have to make something work, introduci…

Both companies I've worked for rely on government contracts, and in general feel pretty calm. It's hard to feel super rushed when the software isn't delivered for a few years. I don't think I make anywhere near industry salary though.

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

#107

Post by m_rpn »

dgb23 wrote: post #76
steveBK123 wrote: post #7

Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…

I don't do "Agile" and never have. But every time I read or hear about Agile it's described like above. Everyone seems to hate it and it all sounds terribly inefficient and frustrating. I scratch my head... Why? Why are people still doing it? Who actually _wants_ that?

We do that, especially in big companies, because management needs metrics, meetings and things like that to keep themselves occupied and relevant.

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

#108

Post by dagss »

drittich wrote: post #91
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.

Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many impl…

Did you look at sp_describe_first_result_set?

https://learn.microsoft.com/en-us/sql/relational-databases/s...

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

#110

Post by x86x87 »

jasongi wrote: post #71
distcs wrote: post #57

Earlier quoted context omitted.

> All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Depends on the workplace I guess. Haven't seen this where I've worked. quite the opposite. Some managers I've worked with taught me to multiple estimates by 2X before writing it on paper.

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.

Post reply on HN