What Do Developers Themselves Say about Code Quality?

Highlights from the New O’Reilly/SIG Report

Evelyn van Kelle
Software Improvement Group
3 min readApr 5, 2017

--

Everyone in software development — from coders to executives — agrees that producing high-quality code is important . . . but what do their organizations DO about it? All of SIG’s work confirms that high-quality software is easier to maintain, cheaper, more secure, and results in better business outcomes. Yet after 16 years in the field, we still see many companies that haven’t dedicated the necessary resources or institutional processes to back up their good wishes for quality code.

We decided to research this further, which led to an earlier poll that we at SIG conducted together with O’Reilly. That poll revealed that:

  1. There often is no shared definition of code quality and how to measure it;
  2. Code quality standards are rarely being used in a consistent way;
  3. The top three reasons for not using software quality standards were “lack of consensus on what software quality is/which standards to use,” “currently has no priority,” and “lack of management support.”

The poll also confirmed our vision that formal training and certification might be the key to maintaining a constant level of software quality.

Hungry for More Feedback from the Field
Those results only whetted our appetite to understand in more detail what developers think about code quality. We had many more questions, including:

  • Who’s considered responsible for code quality within teams?
  • If quality is being measured, is it measured with tools?
  • How useful do developers find their tools, anyway?
  • Which processes mean the most for quality?

We partnered up with O’Reilly again to pose these questions and more to the software community.

Our survey reached a striking 1,442 respondents who were more than willing to share their Code Quality Habits with us.

Being the nerdy data-lovers we are, we could not be happier to share those findings with you in an extensive report. In it, you’ll find analysis of all the ins and outs of the survey data, backed up by numbers, graphs, and everything else you could want. (We know we’re not the only ones who get worked up over data.)

The report contains detailed assessment of responses to survey questions about working environments, accountability for code quality, and the use of code quality processes and tools.

Main Takeaways from the Survey
The general outcome of the poll leaves us with some familiar frustration. It reinforces previous findings that, although code quality is valued in principle, software development organizations often measure and manage it unevenly — or not at all — in their day-to-day practices.

How many wake-up calls does it take to get serious about (measuring) code quality?!

A few major findings reveal that:

  • A large majority of respondents believe that accountability for code quality rests with individual developers and their teams.
  • Most developers don’t use tools for improving software quality, largely because they lack the budget to acquire them.
  • Many developers can’t rely on typical code quality tools because those tools don’t support the technologies and languages they use.
  • Other developers are simply unaware of available tools, or are working with teams that have never used them.

So, the good news is that code quality is perceived as being the shared responsibility of the entire team and individual developers — but unfortunately it is not being addressed properly. To quote my brilliant colleague @JoostVisser once again: “Code quality should NOT be an afterthought.”

It’s high time to put this theory into practice. As the report makes clear:

Only by making code quality an integral part of its ethos and operating practices will an organization create the most value not only with its tools, but more importantly with the coders who use them.

There’s no better place to start than to take a deep dive into the findings in this report.

The full report is available now.

--

--

Evelyn van Kelle
Software Improvement Group

Curious | Trying to make sense of the socio-technical mash-up that is called software development | Social dynamics & Heuristics| Social Sciences|