Much of what comes with being an entrepreneurial leader is knowing when to accept certain tradeoffs. When you have a whole organization under your control it is impossible to constantly uphold a perfect balance; the result is often times compromises and temporary fixes. These compromises and short-term solutions are what is called technical debt. While technical debt is not an inherently negative concept, if left unchecked it become an additional risk in any organization.
At any software company technical debt invariably becomes an important topic of conversation. The focus of these conversations should be on when to let technical debt persist and when to start paying it off. In order to do this though, you need to understand what technical debt entails.
Technical debt is the result of fulfilling an immediate need (with a compromise on the quality of your code) that comes with some serious long-term consequences. And like credit card debt, technical debt has high interest rates that compound over time - making it more difficult to pay off the longer you let it remain in your code.
The CEO of BodeTree discusses how at the inception of any company, in order to find the adequate market fit for their product there is a inherent process of experimentation, adjustment, and iterations of code that lends itself to the creation of technical debt. But when should this technical debt be accepted, and when should you start to plan on paying it back?
If you are looking at a company in its early stages of development then there is likely to be quit a bit of accrued technical debt - this is just part of doing business. So you should be willing to accept technical debt in the following three situations.
- When you are dealing with your first big customer: quick iterative development and adjustments lend itself well to this scenario when you are looking to refine the product quickly to customer feedback. Therefore, technical debt becomes the means to an end.
- When you are building a minimum viable product due to a lack in secure funding: development work is costly so building quick and dirty may be your only option in order to get the product out on the market.
- When you are testing new features in an established product: sometimes a new feature may not even be the right fit for your product or market, so it makes sense to cut corners in development in order to see if the feature is even worth your while.
These are the times when you should let technical debt be; but when should technical debt be seen as an untenable part of your code base?
The time to pay it back would be when it begins to show itself by affecting the performance of your product and the efficiency of the team.
What are the signs of reaching such a point?
You will know that you've reached this point when making changes to your product becomes an arduous task to the amount of features that are interconnected. Your code will become brittle and any change could have some serious ramifications in other areas of your code that could result in breakages and software outages.
For BodeTree the signal was clear when a sudden influx of customers revealed what features were not being used and which features weren't working. The BodeTree team was able to identify what could be cut out and therefore focus on the quality and performance of the code in their system - in the areas that mattered most. A strategy like this saves capital because it allows you to surgically correct the areas where technical debt is the most costly and prioritize your development work accordingly.
The key, as mentioned at the start of this post, is knowing what the right balance is of acceptable and not acceptable technical debt is in your organization.
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.