Why software projects take longer than you think – a statistical model • Hacker News Board

Re: Why software projects take longer than you think – a statistical model

#211

Post by adrianmonk » Tue, Apr 16, 2019, 5:23 PM UTC

dre85 wrote: post #208

I'm blown away on a regular basis by how long it takes to write software that in my opinion is super easy. Usually it just comes down to fuzzy/missing/changing requirements. A lot of times people know that they want something, but they don't know exactly what. Or they're absolutely sure they need feature x, but then later they realize they don't, but they missed out on developing other more fundamental features.

I have developed a belief about this: people don't know what they want until you show them what they said they want. Then it's immediately obvious to them what they wanted instead.

This suggests that demos and mock-ups might be a valuable tool. The sooner you can get someone to try something, the sooner they can tell you what direction they really wanted you to go in instead, and the less time you waste.

Re: Why software projects take longer than you think – a statistical model

#212

Post by dls2016 » Tue, Apr 16, 2019, 5:25 PM UTC

hannasanarion wrote: post #138

thatoneuser wrote: post #8

Earlier quoted context omitted.

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

Wouldn't it be 240%?

ambiguous grammar

Re: Why software projects take longer than you think – a statistical model

#213

Post by afarrell » Tue, Apr 16, 2019, 5:26 PM UTC

dboreham wrote: post #199

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

It's important to realize that the workplace often involves being subjected to what is really a kind of psychological abuse. It is not, I think, a coincidence that we are learning that many "stellar managers" turn out to be abusers, e.g. guilty of sexual harassment. What you're describing is in psychological terms thought of as "maintaining boundaries" against a person who is intent on transgressing those boundaries…

I think “abuse” is an ill-defined enough term that I’m not sure it adds clarity to this discussion without setting out a definition. Its an important subject and might be a really important lens through which to view this, but as someone who has been searching for a really clear-cut definition of “emotional abuse” since my childhood, and who has seen a lot of acrimonious conversations about it since then...I worry that the framing adds more smoke than light to the discussion. :(

Do you have a good definition? One whereby a scrupulous person can confidently judge “am I acting abusively?” correctly?

Re: Why software projects take longer than you think – a statistical model

#214

Post by polygotdomain » Tue, Apr 16, 2019, 5:27 PM UTC

panarky wrote: post #200

artworx wrote: post #150

Earlier quoted context omitted.

I highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers. The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... pleas…

That quiz has an unintentionally apt question. > Total length of the coastline of the Pacific Ocean Coastlines are fractal. If your measuring stick is 1 km long, you'll get one number. If it's 1 m long, you'll get a much larger result. And if it's 1 cm long, you'll get an even larger result. https://en.wikipedia.org/wiki/Coastline_paradox The actual length of a coastline is infinite when measured with an infinitesima…

>The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick.

>In actuality, the concept of an infinite fractal is not applicable to a coastline; as progressively more accurate measurement devices are used

The notion of the length of the coastline, and why I think the question is apt as well, is that regardless of the fractal paradox, the practical answer is that there is an answer that is accurate enough to satisfy the business's or the customer's needs.

The analog for software projects, from my point of view, is scope, and it's generally one of the biggest problems with projects that take too long. Product and various stakeholders take outline broad, high-level scope requirements that may or may not actually be informed by the realities of building or delivering that piece of software. They generally kick the can down the road and take a "I'll know it when I see it" type approach that winds up drastically changing things at some arbitrary point later on on the project.

A rough measuring stick for scope always means that the answer will be longer, however, small measuring sticks for scope are absolutely impractical. What's needed is the understanding from the business that refining scope increases development time, and the high-level broad scope that is sufficient at the beginning of the project is not sufficient at the end. Many businesses want to run with the assumption that their broad scope and the estimates that go with them are accurate enough to bring a product to market.

Re: Why software projects take longer than you think – a statistical model

#215

Post by c0vfefe » Tue, Apr 16, 2019, 5:30 PM UTC

sidlls wrote: post #205

nahname wrote: post #104

Earlier quoted context omitted.

As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

One thing I've learned working in both kinds of companies is that having software as the core concern of the business isn't automatically a shield from bad project management or bad engineering management.

'Not considering software a cost center' is a necessary but insufficient condition for healthy estimation. A software company often appreciates you more, but is still susceptible to the other myriads of management pitfalls.

Re: Why software projects take longer than you think – a statistical model

#216

Post by c0vfefe » Tue, Apr 16, 2019, 5:34 PM UTC

afarrell wrote: post #61

koonsolo wrote: post #53

Earlier quoted context omitted.

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation". In the end, his company went bust because he was selling stuff to customers that could never be d…

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out o…

Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle

Re: Why software projects take longer than you think – a statistical model

#217

Post by Chris2048 » Tue, Apr 16, 2019, 5:36 PM UTC

parasubvert wrote: post #207

Chris2048 wrote: post #88

Earlier quoted context omitted.

A sales negotiation is pretty zero sum. There is little advantage in paying more for the same product. However, Giving a developer more time will often improve the quality of the output.

Price negotiation is not zero sum. Zero sum means one party’s gain is exactly equal to the other party’s loss. Most deals are positive sum - both parties get benefits. Price negotiation is about the seller getting some the upside of the buyer’s benefits but not so much that it sucks for the buyer and not so low a price that the seller will walk. Some deals are inherently negative sum - if you bought a lemon.

If I pay a dollar more for the same thing, I, the buyer, lose a dollar, and the seller gains a dollar. Can you explain how that's not zero-sum?

Re: Why software projects take longer than you think – a statistical model

#218

Post by afarrell » Tue, Apr 16, 2019, 5:37 PM UTC

agumonkey wrote: post #166

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

I wish school taught me how to do your first point. People talk about project management, gantt diagrams and all that but you have no idea how to estimate even grossly the complexity of a thing.

The lack of a good “intro to task and small project management” MOOC or book is a serious problem for our industry’s ability to onboard junior engineers. I wish I knew how to write one, but TBH I don’t know any principles myself except one.

Lots of people say “just do it and multiply by 3” without appreciating that The important part of estimating tasks is coming up with the task breakdown and identifying the risks.

Re: Why software projects take longer than you think – a statistical model

#219

Post by afarrell » Tue, Apr 16, 2019, 5:38 PM UTC

JustSomeNobody wrote: post #151

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

> “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” This is my default. Even when I am fairly confident I know what the code does, I want to double check. And it isn't just so I don't short change myself on time. If I tell them X days and deliver on 0.X days several times, they'll start thinking I overestimate everything…

Its a good default.

Re: Why software projects take longer than you think – a statistical model

#220

Post by Gibbon1 » Tue, Apr 16, 2019, 5:40 PM UTC

parasubvert wrote: post #207

Chris2048 wrote: post #88

Earlier quoted context omitted.

A sales negotiation is pretty zero sum. There is little advantage in paying more for the same product. However, Giving a developer more time will often improve the quality of the output.

Price negotiation is not zero sum. Zero sum means one party’s gain is exactly equal to the other party’s loss. Most deals are positive sum - both parties get benefits. Price negotiation is about the seller getting some the upside of the buyer’s benefits but not so much that it sucks for the buyer and not so low a price that the seller will walk. Some deals are inherently negative sum - if you bought a lemon.

There is such a thing as negotiating too hard on price. The deliverables have lower cost to benefit than if you paid more money. Or worse no deliverables. Worse than that fatal realized liabilities.

I worked with a group that designed telcom IC's. One of our customers developed a new product. Which then failed in the field. The parent company had to issue a recall. Destroyed all remaining inventory and canceled the product. All because someone jacked the microphone supplier down about 5 cents on a part.