Technical Debt is Stifling Innovation; but, There is Hope

June 19, 2018 Bill Graham

Screen Shot 2018-06-18 at 9.19.14 AM

Apple’s recent announcement at their recent Worldwide Developers’ Conference stated they were going to be reducing the feature count in future versions of iOS and concentrate on quality, security and performance. I’m sure plenty of Apple customers are saying “about time!” but it’s a significant proclamation from a top tier technology company. Sacrificing new features for something that should have been there in the first place?

Apple Devices and Bugs over time 

Figure 1: Apple’s major bugs and software flaws and number of devices (in millions) over time.

Despite the potential negative connotation this announcement has, Apple has weighed this against the rising incidents of quality and security issues in recent years. This accumulation of performance issues, bugs and security vulnerabilities over time has accumulated to such a degree that it’s impacting their ability to deliver new functionality. This technical debt which hasn’t been paid in previous releases of iOS is finally going to have to be paid by Apple if they want to keep their reputation as a flagship phone manufacturer. Technical debt affects all software companies to some degree and whenever a bug or performance issues is deferred it adds to the pile of issues deferred previously.

Everyone Starts with Technical Debt

The strict definition of technical debt “the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.” (Techpedia) Extending this to security, defects and performance, technical debt includes the extra cost that arises from delaying refactoring and fixes to a current codebase and any existing code inherited into the project. In early stages of development technical debt is acceptable if not necessary. Time to market and an acceptable set of features is paramount for product success. Looking at the graph in figure 2, the blue line illustrates a typical approach to new product development, where there is a linear relationship between the size of the code base and the difficulty in adding new code. It is more difficulty over time to add new code but remains linear for a certain product size. However, there comes a point where the level effort that can be expended is maximized, either by budget or by physical lack of people to do the work. This point is the scalability threshold, a point where the difficulty in adding new features is beyond the ability of the team to complete.

 Technical Debt

Figure 2: The increasing difficulty of adding new code due to technical debt versus size of the code base. Source: “What is technical debt? And why does almost every startup have it?

Reaching the scalability threshold is not often an observable event or a line in the sand, it’s a slow realization, like Apple has made, that adding more and more features is starting to have a negative impact on other important quality factors. As the difficulty of adding new features increases it limits the innovation possible on the product. As technical debt increases, the ability to innovate reduces over time.

So where does the hope lie? Software companies must strive “to do things differently” and attempt to change the curve to a more logarithmic relationship (see green curve above), where the effort to add new features grows slowly as the size of the project grows. This is done by using new tools and automation, refactoring existing code, and using new development methodologies. Whatever the approach used, there is an impact on the ability to add new features that often requires a step back to concentrate on quality and security as Apple has done.

How does Static Analysis Help?

Static analysis exposes bugs and security vulnerabilities in existing code that are undetected by current product testing. It is also a good barometer of code quality and security and improving important metrics over time can help alleviate technical debt. More specifically:

  • Finds defects before unit testing: Static analysis tools can be used right at the developer's desktop environment and can prevent defects before they enter the build system and the unit test phase of development. 
  • Finds defects that testing misses: Unit testing, even on projects demanding high code coverage levels, can still miss important defects. These
  • Prevents defects in the first place: Enforcing coding standards can help prevent many classes of defects in code. Enforcing good discipline in coding and creating a develop-analyze-test micro cycle for small code changes can prevent many defects from being created in the first place. 
  • Analyzing third party code: Use of third party code such as commercial off-the-shelf software (COTS) and open source software is a fact of life in s software development.  Software for outside sources needs to be managed carefully for safety and security before inclusion in a product.  Static analysis tools can analyze third party source and binaries to discover defects and security vulnerabilities in software that could be impossible to test otherwise.
  • Integration into development lifecycle and complementary tools: Static analysis integrates with and plays a role in a complete ALM suite. Software teams looking to move to the logarithmic curve shows in Figure 2 require comprehensive and integrated tools suites to achieve the required level of productivity.

Although static analysis won’t topple technical debt singlehandedly, it is a critical tool in managing the quality of existing, legacy and third part code. Static analysis also helps prevent new code from increasing technical debt by keeping poor quality code from entering the product in the first place.

Conclusion

Technical debt affects all technology companies eventually. The need to get products to market and defer quality, security and performance issues in order to achieve a viable product is necessary in a competitive market. However, technical debt eventually grows and as it does it impacts the ability of developers to add new functionality and in turn, it hinders innovation. Software teams eventually need to deal with technical debt and adjust their practices to reduce it by adopting new software development practices, tools and automation. Static analysis plays a key role in improving the quality and security of existing and newly written code.

Previous Article
Technical Debt is Stifling Innovation; but, There is Hope
Technical Debt is Stifling Innovation; but, There is Hope

Apple’s recent announcement at their recent Worldwide Developers’ Conference stated they were go...

Next Article
Webinar with AFuzion: Safety, Security, and Agile Development - Pick Any Three
Webinar with AFuzion: Safety, Security, and Agile Development - Pick Any Three

        People often connect safety and security with archaic deve...