[DZone Research] Bugs in Your Code and Performance in Your SDLC

This article is part of the Key Research Findings from the DZone Guide to Performance: Testing and Tuning.

Introduction

For this year's DZone Guide to Performance, we surveyed 473 software professionals from across the IT industry on various aspects of software performance. In this article, we take a look at what respondents told us about bugs in their software and where performance fits in the SDLC in their organization. 

Frequency of Bugs

One of the biggest shifts in this year’s survey was the number of respondents reporting that they needed to solve performance issues on a weekly basis. When asked, “When was the last time you had to solve a performance problem in your software?”, 36% of those who took the survey responded with "this week." That is up from 28% in 2017’s Performance and Monitoring Survey, and 26% from 2016. Conversely, the percentage of those who told us that their application code poses frequent performance issues (the number one issue reported in last year’s survey) decreased from 36% in 2017 to 30% in 2018. Despite this reduction, however, application code still poses the biggest performance issue, by far, for our community. The second most frequent performance issues occur in the database, with 21% stating their database often gives them performance problems (though this number is down from 24% in 2017). Not only were database issues voted the second most frequent, they were also voted as the most challenging issue to fix (of those that can be fixed). 49% of respondents told us that database issues are the most challenging, while 46% stated that application code problems are the most difficult.

Functionality Before Performance

Despite the pervasive nature of the shift left movement in the software development industry, a majority of respondents still claim to worry about functionality before performance, rather than building performance into their app/software from the beginning of the SDLC. Indeed, over the past three years, this trend of building functionally before considering performance does not seem to have ebbed in the developer community. In our 2016 Performance and Monitoring survey, 56% respondents told us they build functionality then consider performance issues; in 2017, this number was 55%; in this year’s survey, the same percentage of respondents as 2017 claimed to code for functionality prior to performance.

If we compare these numbers to the frequency of performance issues above, we find, unsurprisingly, that more problems arise when performance is not coded in from the start. Of those who told us that application code causes frequent issues, 61% said that they build their application and then worry about performance. And, of those who reported to have frequent database-related performance issues, 73% said they worry about functionality first, then worry about performance. Finally, 52% of respondents who build performance in their application from the beginning of development solve performance issues in 10 hours or less, on average; this drops to 38% for respondents who worry about performance after functionality is built.

Conclusion

It seems that the industry standard of creating functionality, then backtracking to make the functionality more performant is one cause of the growing number of bugs reported by our respondents. Is this a correlation that holds up on your team? Tell us about it in the comments!

This article is part of the Key Research Findings from the DZone Guide to Performance: Testing and Tuning.