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.

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