How Technical Debt Can Help You Be Innovative

by

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|