Remodeling software should be done in the same mindset under which we remodel a house: to make it last longer and run better. Companies should be invested in mending their code to be able to get more productivity out of it. In order to get to this point, there needs to be a shift away from perpetually paying down technical debt towards building technical wealth. Within start-up culture there needs to be move away from just tearing down old code, towards deliberately remodeling it.
The first step to doing this would be to rethink the way we define legacy code. A popular definition of legacy code is that it is code without test coverage - this definition, despite being incomplete, is better than the more widely held belief that legacy code is simply old and archaic. Legacy code, in fact, has nothing to do with age and has more to do with how difficult it is to change and improve. This definition of legacy code would include any code that isn't cleanly written, has little explanation, or has no link to the logic and reason behind the decisions made in writing it. If there is no unit testing or documentation present, you are probably looking at legacy code.
If you start thinking of legacy code as code that has no clues in it to indicate what the developer was thinking when they wrote it, then you will begin to see legacy code as the result of failed communication. This post makes reference to something called "Conway's Law": a law that states that your codebase will replicate the communication makeup of your organization. If you want to fix your problems with legacy code, you also have to address the problems within overall operations.
To fix your legacy code, you have to pay attention to the details that make code easier to work with in the future. This means proper and extensive test coverage, explanations for commits, and anything that will make it easier to understand what was going on in the mind of the developer at the time they were working on the code.
However, legacy code is impossible to avoid completely. It will pop up for a variety of reasons. One of the most cited reasons is that in the early stages of company the push to put out new features will overwhelm the need for maintenance. While this is understandable, and even necessary for product-market fit, if this tendency goes unchecked you will hit a point where you can no longer fix your existing code and adapt to the future.
It's the same logic you see in home maintenance. If you don't take out the garbage, or do the dishes, or clean the floors, it will only get more difficult to do over time - until you have to call a team in to haul out the mess that you've left building for months.
So when CEO's complain that what used to take developers 3 weeks to push out to production now takes them 12 - they are missing what we know to be developers battling with legacy code riddled with technical debt. And for CTOs it can be a difficult argument to present that their developers need to go back and work on existing code, because it is not immediately apparent what the benefit of "backtracking" would be.
It is more likely to get your CEO, investors, and stakeholders to support this endeavour if you reframe it as building technical wealth, rather than simply paying back technical debt.
Many start up focus so much of their energy on acquiring talent to build new features and keep innovation levels high, but ignore what can be done to actually increase productivity levels - like paying back technical debt. If debt had been paid off on time, what productivity would there have been left over as a result?
If you focus on the surplus productivity you get from paying off debt, you have shifted your mindset towards wealth building. This will move you away from a focus on the short-term to understanding the value of maintenance. For most start-ups it is had to think past the growth phase, and stability is often looked down on. But all that stability means is that you have the proper processes in place to keep technical debt at pay and accumulate technical wealth - using that wealth on the right set of priorities.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.