Looking at technical debt in a negative light, as something that stands in the way of new features when it grows, equates it to a credit card. If you don't make your payments each month, you are charged interest. If you make only the minimum payment each month, this interest builds and it can take you years to pay off your debt; and if you make minimum payment while continuing to charge more you may never get out of debt. After several rounds of doing this, you will have to announce bankruptcy.
However, having this same view of technical debt is probably too strict to be applied in actual software development.
Technical debt can be can be a tool, similar to when you float a bond at 5% to increase your income by 10%. This means that technical debt doesn't have the same meaning to your business stakeholders as it does to you. If you tell business stakeholders that you can release a project early but you will incur technical debt, to them it will be a no-brainer that you take on that debt. So if you are talking about incurring technical debt, speaking in terms of total cost of ownership may be more useful. You can say that you can release a project early but it will add on three months to the release of the next version; and this will give business a better picture of what it means to take on technical debt.
In the end, you may still end up taking on debt, but at least the understanding of what that means will be there and when you need time to pay it back it will be understood by business and technical stakeholders.
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.