I remember the day one of my first projects reached the “feature complete” milestone, where all the required functionality had been implemented. It is a significant milestone, as the bulk of the project is finished, and only the final touches are left: fixing bugs, making the project production-ready, and finally, delivering the final result. In the project status meeting, I proudly announced that my project was at 80% completion.
Oh really?
There’s a joke that says that software engineering has a perverse version of the Pareto principle, where the first 80% of the project consumes 80% of the allotted time while the remaining 20% consumes another 80%. This project wasn’t the exception: the remaining 20% got more and more delayed until, as the joke says, it took just as long as the previous 80%.
A recent theory claims that Zeno of Elea was working as a software project manager when he formulated his famous paradoxes about motion.
That hadn’t been the first time I’d made that mistake, even as I was already aware of how these things went. I had even told the joke and everything! And now that I have a software engineering newsletter, it is a good moment to explain why we are so prone to be deceived by this milestone. With some luck, neither I nor my prestigious and exclusive readership will make this mistake again next time we are in this position.
A software project contains a lot of tasks: requirement analysis, some design, some implementation, fixing bugs, more design and more implementation, throwing some code in the trash and replacing it with something better, preparing the production environment, alpha testing, fixing bugs, writing the manuals, fixing more bugs, beta testing, fixing other bugs, setting up monitoring, throwing more code out because it doesn’t scale and replacing it with other code that can barely scale, fixing bugs, and finally delivering the project.
The “feature complete” milestone is reached right before alpha testing. When we get to this point, we are so happy with our analysis, design, and all the implementation we’ve done so far that we believe we have nearly finished our work. However, a glance at the list above will show that there is still a lot of stuff left to do, and when you look at them one at a time, it’s easy to see that they add up to a lot of time and effort. Therefore, why do we think they don’t?
There are three reasons for this. The first is that we are consummate optimists. When we make time estimates, we always think we won’t make mistakes or need to undo and redo some of our work. Anyone who’s ever worked on a software project longer than five minutes knows that’s not the case.
The second reason is that in software engineering, we overestimate the importance of programming compared to other disciplines. We don’t only program in a software project: we also write documentation, administer systems, configure, integrate, manage projects, track bugs, and attend meetings to get everyone to agree. When we reach our “80% done” and check what’s left to do, we see a lot of configuration, documentation, and other non-programming tasks ahead of us, so we underestimate them and think they will take less time than they do.
Finally, the third reason is that most projects end in a cancellation; consequently, everybody has started more projects than they have finished. Therefore, we have much more experience with the parts before the “feature complete” milestone than with those that follow it. This lopsided experience causes us to underestimate the tasks we don’t often perform and to work more slowly on them than on the ones we are most used to.
If you don’t want your projects delayed, here are the causes; try to be mindful of them. As for me, I’m going to try to appreciate more the importance and cost of the non-programming tasks, and I’m going to run a few simple projects to practice their final stages so that I’m ready next time.
The illustration for this Coding Sheet is based on a Greek jug.