Originally posted by Code Inspector: https://blog.code-inspector.com/technical-debt-a-software-epidemic-4811838d8e70
Software is like our health: we do not maintain it as we should
Software follows the same pattern as our health. We take it for granted until something happens. We do not take care of it in the early days, believing it’s okay to party, drink cocktails and eat tasty burgers during happy hours, thinking you will take care of your health tomorrow. After a few years of denial, our health starts to show its first signs of decline and it is often too late to take action. We see that everyday: our society has never been so sick and depressed.
We all know the recipe for a good, healthy life. We know the core principles: eat healthy, stay active and sleep well.
The principles for staying healthy are not hard. It is the discipline that is hard. That is why people get support such as getting a coach: a coach is not here to tell you what to do but to remind you of the core principles and to keep you accountable.
Software is no different than our health. We know exactly how to keep software healthy and easy to maintain. And yet, we fail to act on it. We keep piling on new features without thinking about the consequences for the architecture. We forget to document new code because we “need to ship this code quickly”. We keep accumulating issues in the codebase until we realize it is too late and the only measure of our code quality is the number of “wtf per minute”.
Too often, companies act at the last minute, when issues start to be visible. As a result, it takes years to resolve a situation that could have been mitigated over time through regular maintenance. For example, Commonwealth Bank of Australia replaced its core banking platform in 2012, and migrated away from COBOL. It took them five years and $1B of Australian dollars to complete the job -source. Such a transition could have started years ago (we’ve known COBOL needed to be replaced since the 90s) and happened over time.
It is not only affecting old projects. On healthcare.gov launch day, it had an uptime of 43% (systems have normally an uptime greater than 99%). A task force was created quickly to improve the system and bring it to 95% of uptime and handled more than 50,000 users -source. But such issues could have been avoided early in the development process.
But even when companies try to actively maintain their software, they are still being impacted by bad code, which slows down their agility and increases maintenance cost. Even tech companies that have armies of software developers are not immune to these issues. A report from Stripe in 2018 estimates that bad code and technical debt waste more than 30% software developer time. Other studies report similar estimates (see redfin study or pluralsight). When the average of the software engineer salary is around $107,000 per year, it means that companies are spending about $34,000 per engineer per year to deal with technical debt.
We obsess about getting new features out the door without worrying about the long-term consequences. We enjoy the new shiny feature in the short term, but we do not have the infrastructure to mitigate their long-term impact or the consistent code review practices necessary to maintain them. And soon enough, your codebase or health is a mess and there is no way to get it back in shape.
We can stop the technical debt epidemic
As with our health, the rules to keep our software in shape have been well-known for years. The problem is that, as with our health, we do not stick to these rules. If we want our software to stay healthy, maintainable and up to date, we need to invest and commit every day.
Developers need to have a coach that will remind them of what constitutes a clean, healthy codebase. A tool that will remind them that “one more copy/paste to deliver that new feature isn’t going to hurt the quality of the codebase” is just the equivalent of “one more slice of cake isn’t gonna hurt my health”.
Developers need to stick to simple guidelines that guarantee good code quality such as:
- Avoidance of code smell and inefficient patterns that would be bottlenecks
- Do not rely on any deprecated function or library that could impact software security or maintainability (e.g. using strcpy() in C instead of strncpy()
- Avoid copy/paste and code duplication, refactor duplicate code into a function when appropriate
- Write short functions that have a clear scope and are easy to understand
- Consistently document code
- Write tests
These are simple rules and guidelines that developers need to be reminded of on a daily basis, like a coach would remind you to complete your workout every day. Tools can automate verification of such rules and detect if a new code change breaks them. Code Inspector is the coach that will keep your code healthy: it has an automated code review feature that analyzes and annotates each new code change with potential violations. Such a tool highlights issues in code changes so that developers can fix them before merging their change in the main codebase.
It is also important to periodically review your technical stack a few times a year and initiate potential migrations if a technology is being deprecated. If a language (e.g. COBOL or Python 2), a library (old version of Ruby on Rails) or a hardware platform (unmaintained Linux kernel) are being phased out, it is important to be proactive and plan a migration to a newer technology. That will avoid expensive migration in the future. Similarly, if a service becomes too big, it might be a good idea to break it up into multiple smaller services.
Follow Code Inspector on Twitter