Vision is a term often employed to describe leaders: i.e "they have vision" or "they are visionaries". But vision itself is a rather arbitrary term that doesn't necessarily have defined metrics to qualify who has it and who doesn't. In the software world, technical debt maybe the best way to determine who has vision; it is the baseline to see who cares more about the short-term vs. the future.
The most common version of explaining technical debt is that it is the cost of future features; however, what the metaphor tries to truly explain is the balance of satisfying the short-term at the cost of long-term consequences. Given this, technical debt is not necessarily an entirely bad thing. There are certain levels to tech debt that are beneficial to any organization. The amount of technical debt that is beneficial depends on the stage of companies development. For early stage companies the threshold for acceptable technical debt is 40%, for more mature companies 20% tech debt is the max. Once you cross over these thresholds you are running the risk of releasing a product with issues that negatively impact customers - this where technical debt can be severely detrimental to your organization's reputation and customer retention rate. If you operate within these boundaries you are being innovative without necessarily being reckless.
Your technical debt should ultimately decrease as your level of experimentation does. This means that as your product/market fit matures and develops your levels of technical debt should begin to shrink. At this point you should be focusing on doing a few things, but doing them well.
If you begin to drift off into the direction of exceeding these technical debt limits, your organization's long-term goals can come into question. It is common practice that when you need to release a new feature to take certain shortcuts for the sake of making a deadline. Therefore, technical debt is often created in a rush. The issue is that for future releases this technical debt makes it more difficult to maintain productivity levels - before releasing a new feature you have to go and clean up the tech debt that was left over from before.
When you have a single developer working on a project who understands the direct result of the trade-offs that occur when taking on technical debt these issues aren't such a big deal. But when your organization is trying to scale its developer team then technical debt takes its toll by slowing down the productivity of every single new developers who needs to learn what shortcuts have been taken in the codebase. This wastes resources and slows down longterm growth - so any business leader cannot be considered "visionary" if they are letting technical debt get in the way of their organization's growth.
You can also infer quite a bit about a company based on their approach to technical debt. If a company is persistently more concerned about delivering features now at the expense of long-term sufficiency than they're either not going to be around for long, are losing market share to competitors and need to keep pushing out functionality to keep up, or there's a lack of communication between sales and the product team. If you have a lot of technical debt but you're not necessarily pushing out any new features it means you have sloppy developers - but although your developers maybe pushing out sloppy code it is usually the result of a company culture that does not motivate them properly or engage with them to correct the problem. If a company can create new products while maintaining their flagship products, they probably have a handle on their technical debt due to effective leadership.
As mentioned at the start of this post there is a threshold of technical debt that is acceptable depending on the stage a company is at. Gaining visibility and metrics on technical debt is therefore necessary in order to not only keep technical debt under control, but to bolster innovation. There are products that do just this (like CAST AIP) and can be a great asset for any 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.