A distinction that we always try to make in our posts is that there is both good and bad technical debt. This is similar to how there are ways in which financial debt can be used to strategically help a company - it can help develop products faster to get to market quicker. If you incur too little debt it won't have helped you in any significant way, and if you take on too much you will never be able to get out of debt and have created a whole new slew of problems.
In theory, there is no limit to how much you can fiddle with software, if you have infinite time and resources. However, no development team has an infinite supply of either. At some point you will need to stop working on a piece of software, as aiming for flawless bug-free technology will severely limit your ability to response to customer demands. This is where technical debt starts to accrue.
The way to avoid deal with this accrual of debt to figure out the best point within development cycle to incur it and when to pay it back. The first step is to identify where you simply cannot afford to have technical debt. A good way to gage where these areas are is to think about how often you change an area of code. If an area changes often it is not a good place to allow debt to sit as with each change your debt will get larger and more difficult to maintain. But if a section of code is seldom changed it is entirely plausible to let debt sit there untouched for an extended period of time.
Another situation where incurring technical debt is entirely acceptable, is if you are working on a new feature that you are not yet sure will work or not. In this case you want to release it as quickly as possible in order to gather feedback on the feature. Time to market is more valuable than bug-free code. You will have to go back and pay down your debt if the feature remains - but you will have saved time in developing it to even reach the conclusion that it would remain in the code base.
After you have incurred technical debt in the areas that have been deemed acceptable to do so, you need to figure out how much time you need to set aside to pay back that debt. This is where the cultural component of technical debt comes into play. For many developers it can be infuriating to have to take short cuts in writing code, and if they are never allowed to make time to pay back debt it can become demoralizing. It is thus necessary to openly discuss technical debt, where it exists, and create time tables for its repayment. Creating projects for the repayment of debt will also reduce risk in the codebase.
Technical debt is not entirely good or bad - it's how it is managed that helps define whether it is adding value or taking away value in the development of you project. Tech debt is can be extremely helpful in making time to market, but if it is used irresponsibly it will sully your codebase.
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.