A few months ago, I published a survey to gather some insights into how teams and individuals see legacy code. While the response was smaller than I wanted, it does provide some interesting data. As promised, here are the results.
The Most Important Bits
- A total of 50 people responded. I had liked to see more of course, but we’ll have to do with this limited set of data.
- The vast majority is familiar with the terms legacy code (98%) and technical debt (91.8%)
- The biggest impact of low quality code is felt in slow development, regular bugs and low morale. Three aspects that are detrimental to any team or business.
- The most popular ways of managing code quality are automated tests, monitoring and code reviews. Pair or mob programming isn’t popular at all.
- Teams feel that code quality is better if they write automated tests as a standard practice.
- Developers and architects are slightly more inclined than management to feel that there is not enough room for tackling code quality issues.
Is Low Quality Code A Big Issue In Your Organization?
Over all respondents, low quality code isn’t always regarded as a big issue. The distribution is fairly equal, although only a minority feels it isn’t even a problem at all. This could indicate that most respondents feel there is always room for improvement.
If we split up according to role or org size, I don’t think we can see any real trends. This might indicate that it very much depends on the specific respondent, team or organization.
Symptoms
The top three symptoms that respondents see coming from low quality code are regular bugs, slower development and low morale. If we combine the scores for “low morale” and “stress & frustration” (without counting doubles), 74% of the respondents feel low quality code has an impact on mental and emotional wellbeing.
Curiously, only a tiny group feels that low quality code hinders them in testing the software.
As for the “other” category, here are some interesting responses:
- Scalability suffers
- We suffer more from low quality code of third-party services and frameworks than in our own code
- Onboarding new developers becomes more difficult
- App performance suffers
Management Tools
To manage the quality of their code, most respondents indicate they use automated tests, code reviews and monitoring. A little over half also use code analysis tools. To me, this indicates a fairly mature audience in terms of software development practices.
Interestingly, pair (or mob) programming isn’t very popular. While a useful technique, not everyone is a big fan of it and teams have seen success without it. Something that is rare in teams that don’t use automated tests for example.
Also a good sign is that for at least half of the respondents automated tests are standard operating procedure. For another 34%, it’s a bit of an afterthought, but this group isn’t necessarily anti-test. A small group doesn’t use them at all. This group is most at risk of having a low quality codebase over time (if not already the case).
Code Quality
If we look at how respondents feel about their code, most feel the quality is average or better.
But if we look at the group that uses automated tests as a standard practice vs those that don’t, we see that they feel better about their code:
Release Cadence
Most respondents indicate that they release weekly or monthly.
A small number releases daily and there was also a respondent that released whenever a new feature was finished.
Several respondents release only a few times each year. I would have to know more about the project to determine my opinion on this. Not all projects are fit for or even require daily releases.
Fixing Code Quality Issues
There is room to fix code quality issues. Only a small number of respondents indicated there was none at all. But overall, it seems we want a bit more time, budget or resources.
Interestingly, if we split up by role, we see that developers and architects are slightly more critical than management to the amount of resources available to fix these issues.
Roles
I categorized the different roles in three categories:
- Developer/Architect
- Management
- Other
You might argue that developers and architects aren’t the same, and you would be right. But in most cases, they have a similar level of knowledge about code and architecture. They can talk about these subjects and understand each other.
Management roles include things like VP’s, CTO’s and Product Owners. While they may come from a technical background, these roles don’t necessarily require deep knowledge of the code.
There were several roles that didn’t warrant a separate category. Things like administrative employee, technical support staff and business experts.
As you can see, the respondents can be found mainly in the developer/architect role:
Organization & Team Size
As for organization size, most respondents work in larger companies.
Teams are generally between 2 and 10 members, which is a good size. It contains enough developers to be productive without being too large to become chaotic. If you’re wondering about the large 51+ team, this was the response of a Head of Technology. So this is the department we’re talking about.
If we spit this up per organization size, we still see that smaller teams are preferred.
Final Note
I originally thought to make this a larger survey. Unfortunately, I got less responses than I had hoped for. I had also wanted more responses from management roles. But it was an interesting exercise nonetheless.
It seems that most respondents are aware of the problem with bad quality code, which is a good thing. Automated tests are the number one tool to keep code quality high. Although half of the respondents feel the quality is average or worse, that still means the other half feels good about their code.
Thank you to everyone who responded!