Slashdot Mirror
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?
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
Mr Scott, have you always multiplied your engineering estimates by a factor of four?
Oh, laddy, you got a lot to learn!
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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.
See that "Preview" button?
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.
Your'e all thinking it, I just said it for you
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.
Irony: Agile development has too much intertia to be abandoned now.
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.
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.
Proud neuron in the Slashdot hivemind since 2002.