Technical debt is defined, in this post, as any code that impedes agility as a project matures. This is an important definition to keep in mind as the following attitude towards technical debt is discussed.
One of the reasons that so many start ups fail is because they take too long to get their product to market, and it causes marketing efforts to stand still or become irrelevant. This allows the competition to come in and take away the market opportunity. It is therefore possible to say that a software company’s success has less to do with having perfect code or systems and more to do with delivering an efficient and valuable product to market at the right time. It is not realistic to design a product for first launch that is entirely perfect – it will often take several iterations of change and feedback to have the product reach its full potential.
It is then interesting to question why building software is seen in a manner that does not match the reality of how projects and products are produced and launched. A good comparison made in this post is to the construction of some of the world’s largest cities – New York and London were not built with the prospect of housing millions of people in mind, but they improved overtime and added infrastructure to accommodate these changes. This demonstrates the issue with an engineer wanting to scale their project for one million users in the first launch – the possibility of that traffic is slim and therefore unneeded resources were spent building for it.
When discussing how to manage technical debt, in strategy, there are certain areas that require more attention than others. There are also areas that require intense scrutiny and a hard line against accruing technical debt. This sort of strategy demands an awareness of what aspects of a product need the ability to change rapidly. It is then okay to state that some areas of an app or project are not at serious risk by incurring technical debt. The reasoning behind such a conclusion is that technical debt hampers agility and makes the process of making changes in an application much slower, but this is a disadvantage only if an area requires a lot of change.
**Disclaimer: technical debt is not buggy code or a system that is broken – because these issues will cause damage to code if left alone.
Considering how it has been stated that there are areas in a code base which require more attention than others regarding technical debt, what are these so called areas that are more at risk to the presence of technical debt?
They are the following:
- User Interfaces – this part of an application requires considerable change and therefore needs to remain agile in order to be able to accept changes quickly and effectively. This has contributed to the popularity of single page applications – they allow for quick agility without API changes.
- Data Structures – it is said that bad programmers worry about the code, while good programmers worry about the data. The first part of any project should be dedicated to ensuring that its data structures are well done. For example, if a relational database is being used and modules are awkwardly placed, it will incur massive frustrations later on.
The best method to implement a strategy that will allow a different levels of attention with regard to technical debt (depending on the area most vulnerable to it) would be to segment the code base into specific areas of concern. If the work is divided into separate ‘silos’ then it will not matter if there is substantial technical debt in one area because the system has been decoupled. When putting in testing into place, the areas where the most traffic is expected needs to have the most extensive testing applied.
The general concept of this post is to know the impact and larger perspective of what is being worked on – so as to be able to prioritize in managing technical debt. The final conclusion is that technical debt is often fine to have, as long as it is taken care of in a savvy manner and is used to get to market as quickly and as effectively as possible.
To read the full post go to: http://bigeng.io/post/118399425343/why-the-way-we-look-at-technical-debt-is-wrong
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.