What is technical debt
The implied cost of future rework when a solution prioritizes expedience over long-term design
Manifestations
- Resiliency, efficiency, security issues in own code
- IP, safety, obsolesce issues in OSS components
- Sub-optimal use of cloud
- Design architecture deviations
- Poor technical documentation
- Takes forever to change applications
Good debt vs bad debt
Good
Incurred to foster innovation without significantly affecting the business
Bad
Impedes business performance, agility, safety, and resiliency
The key is finding the few pieces of code that have the most significant negative impact on the business
Mapping the software landscape
Shortlisting applications
- Map applications by tech-debt density against business criticality
- Focus on critical applications with high tech-debt density
- Consider critical, large applications with low tech-debt density
- In this real-life example the scope is reduced from 50 MLOC to 12 MLOC
Bird’s-eye view of a portfolio of 300 custom applications, generated by CAST Highlight
See the big picture
- Scans source code repositories
- Analyzes all applications for
- Technical debt density
- Cloud maturity
- OSS risks: IP, safety, obsolesce
- Maps empirical findings against subjective data, e.g., criticality
- Recommends best path forward
Picking the targets inside the selected applications
‘8% of total defects, result in 90% of the significant reliability, security, efficiency issues in production.’
‘Engineering rules for finding the most critical flaws [the 8%] by assessing software structures in context’
Traditional (syntax) analyzers miss the context
Bad can be good
Performing a table scan instead of using an index affects performance. But it makes little difference for a reference table with a few entries.
Good can be bad
A real-life scenario where the code unit is beyond reproach, yet system performance suffers.
Semantic analysis is required
Pinpointing the 8%
- Involves 10,000x of code units and their numerous interactions
- Requires examining the meaning of every unit in the context of all interactions across all tech layers
- Fastest way is to use semantic analysis technologies, such as CAST or Coverity for C++ code
Internal map of a mid-size application with 300,000 LoC and 41,000 code units. CAST Imaging
See inside applications
- Ingests source code, data scripts
- Analyses all units’ semantics
- Generates maps detailing
- Internal architecture
- Major structural flaws +
- ISO 5055 adherence ++
- Architectural rule deviations
- Provides recommendations and natural language explanations
What else can be done
Feeding AI to correct issues
- CAST creates deterministic call graphs at 40 KLOC per minute
- Feeds prompt engineering for GenAI tools with generated call graphs
- GenAI generates corrected code, while minimizing the risk to the system
- Prototypes with several companies fully automate up to 20-30% of remediation
- SMEs still needed for complex issues or extensive changes, such as refactoring
Preventing the past
Applying the 8% approach proactively
- Deploy a Structural integrity gate examining the entire application before changes are sent to production
- Focus on the 8% of flaws that most matter
- CAST Gatekeeper is specifically built for that purpose
- Analyzes semantics
- Follows ISO 5055 rules
- Recommends remediation paths
- Connects to issue tracking systems (ITS)
- Available stand-alone or as CAST Imaging extension
Action plan for correcting structural flaws as seen in CAST Gatekeeper