Ask Slashdot: Are Accurate Software Development Time Predictions a Myth? (medium.com)

New submitter DuroSoft writes: For myself and the vast majority of people I have talked to, this is the case. Any attempts we make to estimate the amount of time software development tasks will take inevitably end in folly. Do you find you can make accurate estimates, or is it really the case, as the author, DuroSoft Technologies' CTO/Co-CEO Sam Johnson, suggests via Hacker Noon, that "writing and maintaining code can be seen as a fundamentally chaotic activity, subject to sudden, unpredictable gotchas that take up an inordinate amount of time" and that therefore attempting to make predictions in the first place is itself a waste of our valuable time?

Comments

Yes, but...

[Anonymous Coward]

Try getting a contract awarded with "It's too chaotic to tell"

Re:Yes, but...

[Dutch Gun]

The problem with software development is that unless you've done that exact same task before, you really have no idea what's involved. And if you HAD done that exact task before, you wouldn't need to be doing it again, as you could re-use most of your previous work. Unlike with, say, constructing a building, once software is well-built once, it doesn't have to be built a second time, at least within the same company, or if its open source.

Management is also to blame on occasion. I put together a schedule for a videogame project for a major publisher, and the schedule was rejected, saying it wasn't detailed enough. They wanted finer-grained breakdowns of tasks, so instead of one to two week tasks, they wanted one or two day tasks. The only problem: the game wasn't even designed yet - only a rough idea of the genre and licensed property we were using. So, someone (not me, thankfully) dutifully put together a bullshit schedule with fine-grained bullshit tasks, and as the due dates arrived, we simply checked off those tasks in our official project management software.

In the meantime, we had our own spreadsheet with our real tasks and timelines that we used internally, although we tried to match up major milestones as best we could. Since it was a hard deadline, we finished the core game systems as soon as possible, ruthlessly cut extraneous features, and still delivered on time. I'm sure the publisher's producers still think it was their detailed scheduling that kept everything on track.

Re:Yes, but...

[utahjazz]

This is exactly right. Unfortunately so many people think that constructing a building is a good analogy for "constructing" software, and think the same methods and ability to schedule in detail apply. It's the worst analogy. A better one is, making a schedule for the invention of a flying car. You know exactly what you want it to do, but you don't know how you'll make it happen yet, and you certainly don't know the exact date when you'll have it all figured out.

Re:Yes, but...

[computational super]

partly explained by a sort of optimism.

Well, maybe a little, but I think it has more to do with every request for an estimate being something along the lines of, "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." When we're young, this freaks us out, and we try to talk them back from the brink of insanity and get them to see that this is definitely more complicated than two weeks, but they beg, bully and cajole until you break down and agree, certain that you're going to be fired (from your first job!) after just two piddling weeks. So you put together what you can, it doesn't work, two weeks pass, you keep working, nobody fires you, nobody even notices that you slipped the estimate. You keep working on it, the boss keeps asking "is it done yet", you get really good at apologizing and explaining that the network didn't work the way you thought and the new version of the database is different than the old version in undocumented ways, and a few more weeks pass and you get something working, and they say it's shit, and you go back and make a bunch of modifications and they keep asking is it done yet and you keep apologizing, and three months later you actually have a decent working product, and nobody fired you, and the company didn't go out of business because you blew your estimate by a factor of 6 and everybody actually seems reasonably happy.

And then they come you and say "I'm not really sure what I want, and I need you to estimate it, but the budget only allows for two weeks, so you should probably not say anything more than two weeks." And you start to protest, but then you remember last time, so you say, "yeah, sure, two weeks, whatever dude," knowing that it doesn't matter and gradually coming to the realization that you're just playing a game whose rules aren't written down anywhere, pretending that you can deliver anything in two weeks, knowing that they know you can't, but both of you are playing a game of chicken at the end of which nothing happens.

And then after lather-rinse-repeat for 30 years, you go on to slashdot and you tell the young kids, "just give them the number they want to hear, nobody takes estimates seriously anyway" and some loudmouth PHB who figured out how to turn on his computer replies back "they're going to offshore all of you if you don't start producing accurate estimates because there are real-world consequences for missing dates" and you shrug your shoulders and go back to work because you know that the offshore people can't estimate any better than you can and the only people who insist that software estimation is realistic are the people who wish it was realistic, not the ones actually expected to produce it.

This always worked for me...

[Anonymous Coward]

Take your developer's estimate
Increase that by 40%
Double that

It seems incredibly arbitrary, but I have learned that the 40% covers testing and implementation, while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.

Try it, you'll like it

Re:This always worked for me...

[ls671]

Back in the old days, we would simply tell our managers; "We will make it and then, we will tell you how long it takes".

Re:This always worked for me...

[Anonymous Coward]

Take your developer's estimate
Increase that by 40%
Double that

It seems incredibly arbitrary, but I have learned that the 40% covers testing and implementation, while doubling the entire amount allows for the customer seeing the first result and _then_ telling you what they really want.

Try it, you'll like it

HA. You have no experience in management obviously. Here's how I do it:

Take the developer's estimate
Tell them it's too long
Halve it
Tell the customer
Project gets behind
Start the death march (60+ hours for everyone but management, we have families!)
Project gets behinder
Customer is pissed, but doesn't really have any other options
Project comes out OK, but is much later than even the original estimate that was halved
Customer is happy, management is happy, engineers are disposable
Go to Hawaii with my bonus!

engineering estimates in the future

[ooloorie]

Mr Scott, have you always multiplied your engineering estimates by a factor of four?

Oh, laddy, you got a lot to learn!

Yes, inherently unpredictable, needs percentages

[SuperKendall]

Even with known and well understood languages/technologies/frameworks, you can and will run into glitches that can take days to complete something that was supposed to take hours - or even longer if the developers are not skilled in debugging and isolating problems!

StackOverflow has helped the industry in this regard, because now a lot of times you can reduce some mysterious problem to a fifteen second StackOverflow search which instantly answers the issue. But not always, and there are always issues when actually programming any design that you can uncover hidden flaws and need to correct them.

What I would love to see is some kind of approach that instead of a time estimate, gave a time along with a percentage of confidence. Two different tasks may seem to take about five hours, with one you are 90% sure it can be done in five hours, with another (like brand new code) it can be more of a 50% five hours. Then you could use this percentage to determine the actual areas of coding likely to cause schedule issues and monitor them more closely. The other nice benefit of this approach is that it factors in the actual developer understanding and abilities more than just a straight hour estimate. Maybe you even put a cap on how high a confidence level a developer is allowed to give until they have met given estimates a number of times already...

Coding is a chaotic system, yes, but it's not like it's fully chaotic, and there are patterns within the chaos I think you could determine over time.

Re:Yes, inherently unpredictable, needs percentage

[networkBoy]

This:
I always provide my managers with confidence interval estimated times
50% 10 days (assumes *nothing* goes wrong, no interruptions, and high code reuse)
90% 15 days (assumes no catastrophic issues, no interruptions > 2 hours and only 5 of them, moderate code reuse)
100% 55 days (the wheels fell off, severe schedule impacts of interruptions non stop, no code reuse)

My boss laughed at my 100% estimate until it actually happened.
A lead dev (who could be counted on for sound advice delivered in a belittling way) was struck down by lung cancer and ceased to exist. Another lead dev who was even brighter, and much nicer to work with was poached by a competitor, both within days of each other. The code was cutting all new territory in the system, so maybe 15% reuse? *and* some panicky manager started having $deity damned _daily_ meetings about it.

We almost missed my 100% date, made it by about 16 hours.

Solved problem

[Orgasmatron]

https://www.joelonsoftware.com...

This is one of his blog posts that is almost an infomercial for his product, but he does describe the concept well enough that you could roll your own if you wanted to.

Re:I Have No Trouble Making Accurate and Precise..

[scdeimos]

Yes, this. Good management knows that you know your trade and accepts your estimates. Bad management thinks they know better and try to negotiate on estimates.

Over the years I've found that feature development, particularly adding to existing systems, will get better estimates if we're allowed a spike to review the affected areas up front - this is when you discover unexpected dependencies or just sheer awful spaghetti. When you're not allowed to do this up front is when you come across the unexpected gotchas that blow out the best estimate you could provide at the time.

Re:No, but they require planning

[Tablizer]

The product was finished as described in the requirement documents, but generally didn't work 100% like the customer expected.

Yip, generally it's easy to make an estimate for a clear specification. But, customers rarely know what they REALLY want until they see something in production. This is a very common problem. I don't know any easy solution to that: mind-reading machines don't exist.

One partial solution is for the technical analyst to become a domain expert first. But obviously this is often not practical. Further, sometimes the main customer/manager wants something rather odd that is a quirk of their personality. You may build something that fits the domain, but they want to see their domain in peculiar quirky way.

Another partial solution is "RAD": Rapid application development tools. Someone who knows the tool well can usually spit out something pretty quick and change it fairly quick.

However, RAD tools are not known to be very flexible in the longer run, such as when UI styles and expectations change. They achieve RAD in part by marrying business logic to the UI. This marriage makes less "marshaling" code between the database, biz logic, and the UI; BUT also hard-wires it to UI assumptions. Keeping up with the UI Kardashians can be a major PITA. Just when GUI's were maturing, web came along. Just when web was maturing, multi-device-handling needs came along. The current "in" thing is going to be klunky because it's not mature yet.

For now, it looks like we are stuck with some degree of organic meandering to get something the customer is actually happy with; but organic meandering takes more time and money and is hard to estimate up front.

Re:Each dev consistently off by a constant factor

[vlad30]

Developer’s and programmers have relatively poor time estimation skills. The one thing that makes them good is focus and getting lost in a problem often getting lost in the work and waking from this extreme concentration days later not realising how much time has passed and only counting the final Eureka moment where the programming was quick. Then when asked next time for a expected time they estimate the perceived time of hours not days or weeks.