How Innovation Debt Is Just As Damaging as Technical Debt

by

Often times in the development process large amounts of technical debt result in stalled innovation from a given team. However, what happens when what is stalling innovation is not only poor development practices but insufficient investment in developers themselves? This would be what is called, in this article, innovation debt. This sort of debt is comparable to technical debt in that a lack of attention to maintaining clean code results in long term deficiencies, the same way that a team which is too busy preparing new features for an app can't learn about changes in languages, frameworks, libraries, or tools.

Over time a poor codebase will become extremely costly for an organization, and the same can be said for a lack of training and free space as it limits a team's productivity and will make it so a team no longer has the skills to properly maintain in-house legacy systems and applications.

This innovation debt reveals its costs in the following terms:

  • Your best developers will start to leave
  • It will then be more difficult to fill these vacancies
  • Productivity will begin to fall
  • And your software will become brittle

So how do you avoid building up innovation debt?

Ultimately, the components that are necessary for continued training have to be incorporated into your corporate structure. This is just how organizations should be dealing with technical debt: baking in good coding practices into their business processes. For dealing with innovation debt these continued training practices could manifest themselves as monthly meetings where team members present an interesting issue area they have worked on or as a company directive to send developers to conferences in order to keep up with the latest trends.

Prioritizing knowledge sharing whether from external or internal sources is integral to raising the threshold for collective team knowledge and skill. However, this new focus on experimentation and learning means that an acceptance and expectation for failure also has to be taken into account by the organization. Trying out new methods and technologies comes with inherent risk; therefore, creating an environment where failure is not immediately reprimanded is conducive to innovation. Invaluable learning can take place from what seem like purely failures - your team can begin to form its own framework on what technologies work in a given circumstance, and which do not.

To read the full post innovation debt and how to avoid and manage it, 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

|