We hear it way too often in the news: another digital product has failed miserably. This can make us wonder: can we really trust digital solutions nowadays? Why do these failures keep happening? Based on my experience, there are three main problems when building software: unstable objectives, bugs and technical debt.
What can we do to address these difficulties and build trust with the public? In this series of articles, I will share my opinion, providing reflection on three potential solutions: production time budgeting, error and exceptions management and over-use of resources.
Photo: xkcd
Budgeting production time
The first big piece to address is development time. Software development has a terrible reputation in terms of projects going way over budget and having major delays. But what causes delays? Some of the culprits could be: the constant change of the software objectives (“moving goalpost”), bug resolution, technical debt and its correction, also known as refactoring.
Moving goalpost
The moving goalpost is an unfortunate consequence of Agile development. The strength of Agile methodologies is that it allows development teams to react quickly to the needs of clients and their feedback. However, there are situations where the owner of the product will change their opinion after work has been completed on existing features. Those change requests have a consequence: each rewrite and each additional feature add to the time it takes to develop, which contributes to going over budget and over time.
To avoid this, it’s key that the client or product owner issues a document with the detailed features and specs that their software requires early in the process, and follow it closely when possible. It’s not always easy, but the team must try to stick to it, if they do not want to face the consequences of delays or going over budget.
Bugs
It’s important to understand that every time that a bug is uncovered, it takes additional time to correct it. But why do bugs happen? It is pretty much impossible for a software to be 100% error free. The probability of a bug occurring in a product is proportional to the complexity and size of the project in the best of the worlds, and exponential if the project is built very fast. Bugs can occur at various moments during the creation of the product, but the latter they are uncovered, the costlier they are to repair as the complexity of the cause behind the bug and the impact of the bug are bigger.
In today’s world, business needs require development teams to build digital products quickly. The outcome: The more we ask the team to build quickly, the less time they have to allocate to verify the code and execute tests. If Agile is an opportunity for developers to be aware of business needs, it should also be an opportunity to listen to the experts that are working on the products.
A rigorous process of code review and testing is recommended to decrease the occurrence of bugs early on. My other recommendation is to invest in a good testing team. A good tester that can find the bugs early in the production cycle and document them well, can save a ton of time for the development teams.
To help yourself, take into consideration the time required to correct bugs in the initial estimates and make sure you have a solid testing team to limit the negative impacts of bugs.
Technical debt
Two elements that can contribute to technical debt: complexity of code and time constraints. Even if these two problems appear completely different, they are highly related. Why? A development team that is in a hurry will not have the time to abstract the code and generalize it, which would have helped give a better diagnostic on existing code. They also won’t take the time to produce tests or document their code. All those shortcuts, while welcome by the clients and project managers that see the project move forward quickly, will turn into major slow downs later on.
A new developer joins the team? It will take them longer to understand the code and achieve a good velocity. A bug appears? It’s harder to understand its cause and correct it. This correction will have more risks of generating unwanted effects on the product. Adding a new feature will take more time, as we need to spend more time to find the right way to integrate it in the product without causing side effects.
Technical debt has a radical remedy: Refactoring. It's a painful and long process that often requires a lot of time to understand the code base, build tests and rewrite parts of code the right way. Of course, this solution is never popular by decision makers. You want to take more time to rework a product that is already functional? Nonsense! However, you've got to understand that this radical remedy allows you to gain back that time in the long run, as the technical debt grows exponentially with the development of products.
That’s why it’s important not to fall in this trap early on. How to avoid it? Programming standards that are clear and applied in a rigorous code review process will contribute to decreasing the risks behind the technical debt. In addition, having clear objectives early on in the projects allows the conception of clear and solid architecture, that will not only help decrease technical debt, but will also ensure a good velocity from the start.
In conclusion
Time, time, time. Going over time and budget is the nightmare of each product manager. That’s why it’s important to well understand the key issues that software projects face: changing objectives, bugs and technical debt. « Slow is smooth, and smooth is fast. » Allow enough time for your team to create the product that will make your company grow, and you will have a high-quality product from the start, while respecting your budget and timelines.
If you are looking for further information on how to repair trust in numeric solutions, take a look at the second post of our series on how to handle and reduce the risk of exceptions.
Photo credit: Claudio Schwartz Purtzlbaum
