By Frances Lash On August 25, 2016 At 3:43 pm
Category :Articles, Blogs , Uncategorized
Tags :Code Quality, Software Development , Software Maintainability , Technical Debt
Responses : No Comments
This is a great post from the Software Engineering Institute on early software defect detections with technical debt. Schwartz, the author of the post, starts of by outlining the struggle that software engineers face balancing what is quick and desirable in the short term against the complexity and high costs that a short term approach will have in the future of the software the build. This sort of tradeoff, between short term rewards and long term maintainability, is what often leads to technical debt .
Something that we often talk about on this blog, is that if you don’t pay back technical debt in a timely manner it can have pretty negative consequences. It can lead to a higher likelihood of defects, unplanned work, and difficulty in implementing new features due to the nature of the code that technical debt resides in. However, the question that is explored in this blog post is whether technical debt also correlates to an increase in system vulnerabilities.
Schwartz goes forward trying to answer this question by outlining the research done between software vulnerabilities and technical debt.
Their approach involved:
Identifying Security Vulnerabilities Identifying Technical Debt Model a relationship between signs technical debt and how vulnerabilities were affected by these signsOne of the first findings from this post is that when developers discover security issues, they often speak in terms related to technical debt. Developers will discuss getting to the root cause or comprehendingthe underlying design an issue. They will also speak about those areas where changes take longer than usual to implement or where a problem is reoccurring which leads to the ability to see how a certain area can need a bigger fix in the future.
The signs that demonstrate a presence of technical debt are the number and type of design flaws that exist within a system (traditional bugs, security bugs) as well as the number of lines of code that need to change in order to fix a bug. Ultimately, from the SEI’s research, they discovered that the more types of design flaw that file is part of, the higher the likelihood that the file also has vulnerabilities.
The second finding made in this post is a correlation between software vulnerabilities and technical debt indicators. If we look at the previous finding we see that design flaws are often spoken about using concepts closely tied to technical debt (code that is slower to change and causes reoccurring difficulties) and that design flaws lead to a higher probability of software vulnerabilities. What we see is that files with vulnerabilities tend to have a high amount of code churn (the number of lines of code that need to be changed in order to fix a bug).
While the purpose of this post was to answer the question whether software components with technical debt more likely to be susceptible to vulnerabilities, the sample used to to research for this post was too small to come to a definite conclusion. But, while this post may not answer the question definitely, it is something to keep in mind when you deal with technical debt, and perhaps by combining the evidence found in this post and your own experience you can start to see whether there is another reason why you should be on the guard against technical debt.
To read the full post visit here .
Paying Down the Interest on Your Applications:
A Guide to Measuring and Managing Technical Debt
Technical Debt helps us think about software quality in business terms. This FREE whitepaper includes a formula to benchmark your Technical Debt against industry data, or adjust the parameters to best fit your organization’s own maintenance and structural quality objectives, experiences, and costs.
Get Your Free White Paper Now!
Your Information will be kept private and secure.