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