Do completion dates for your software development projects recede further into the distance as soon as they approach? The causes are predictable as well as preventable. The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — Tom Cargill, Bell Labs As humorous as it might sound, this aphorism has the ring of truth if you’ve ever been involved in software development projects.
It is a close relative of the pareto principle, which states that 80% of outcomes have their roots in 20% of the driving factors. In business contexts, the pareto principle helps bring into focus vital customer segments, key issues to prioritize, and which products and services to double down on.
However, when it comes to software development, watching this principle unfold in practice can lead to nightmare projects that never end and mirage delivery dates that recede into the distance as soon as they are approached.
At Gigster, we have managed hundreds of projects involving thousands of milestones, and have had customers come to us after facing these kinds of difficulties in their own internal and outsourced software development projects. There are many ways projects can run into trouble, but when it comes to this particular failure mode, here are three cases which are frequent predictors of final delivery mirage.
It might seem obvious that an organization building software should know what it is building and for whom, but we have found this to not always be the case. A system can be born with different (often multiple) use cases in mind, and those with input into what gets built are sometimes not the same as its actual end users.
Add in organizational changes and shifting priorities, and you can be left with original intentions residing in ancient history. This can lead to situations where once a product is theoretically ready, it is not accepted as complete by stakeholders whose input wasn’t actually considered, leading to significant mid-stream corrections and rework.
Terms like “Proof of Concept,” “MVP,” “Prototype,” and “V2” often circulate, sometimes interchangeably, but they have distinct meanings that require disambiguation. A Proof Of Concept (POC) needs to have a target concept to be proven out; a minimum viable product’s viability is dependent on its intended utility and customer base; prototypes should have a purpose, and someone’s Version 2 is another person’s Version 3.
It is important to not shift goalposts and have clarity on whether what is being built is temporary, foundational, or reusable. Having a multi-stage program for software development that evolves through various iterations towards a north star is a healthy cadence, but not knowing where you are in that journey is not.
If you’ve ever watched a skyscraper under construction, you’ll recall that for a long time the most salient feature will be a hole in the ground, and then later on the many levels will rapidly go up. Similarly, with software projects there are key components that must be developed that will not be visible to stakeholders and end users.
This fact can be at odds with an urge to show progress, sometimes leading to early demos of visible front-end features that don’t have much purpose other than to show work has been done. In keeping with the principle of “prototypes should have a purpose”, there can be good reasons to show and even test certain features early, in particular to elicit feedback at the right time or to show a concept come to life in a way that might not otherwise be intuitive, but development teams can get lost in building for the demo without regards to what comes next.
Individuals and organizations know that they should manage debt responsibly, but one of the consequences of the factors mentioned above is a large amount of technical debt growing under the radar of project sponsors and even project managers.
Time-consuming and/or difficult development and implementation aspects can end up being deferred without regard to true level of effort. This can manifest itself in both visible front-end features as well as back-end aspects such as data processing. As an example, user interface elements might appear to be “80% of the way there” and need more polish but could in fact be built in a way (through a framework or an “out of the box” module) that makes customization extremely time-consuming.
On the backend front, a process might work fine with simple sample data, yet completely fail when tested against data representative of real-world use. In both of these situations, a demo might show both quick progress as well as hide steps taken down the wrong path.
If you already have projects underway and some of the situations mentioned above sound familiar, don’t despair. The best time to prevent the situation would have been prior to starting development, ideally through involving a trusted development partner at an early architectural scoping and design phase, but it is never too late to get back on track.
Our services, including code reviews, architectural assessments, and refactoring evaluations, can help you set a path forward to timely outcome-focused software development.
