Home Home Posts Rants about IT DevOps Stuff I'm working on

Don't ask writing good code

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
112
articles
January 8, 2014

What a surprise. After being asked for months to simply write code as fast as possible, with no thinking or testing, management suddenly criticized one of the colleagues, because the code of a new, unstable feature implemented today contains long (more than 50 LOC) methods, suggesting to write shorter methods in future.

At first sight, it's a good sign. What would be better than to encourage the team to improve their code quality? But after a thought, it may be not so obvious. Definitely, management is wrong, and by wrong, I mean plainly, totally wrong; no reservations.

Firstly, you don't start writing good code over thousands and thousands of lines of bad code. It's simply not working this way. Not only because the natural evolution is continuous decay, not improvement, but also because project culture is forged through time, and cannot be changed immediately at will. Project culture—an obviously unclear term—deal with the attitude of the team towards code, towards their colleagues or towards management, the project values, the expectations, the interest, etc. Project culture may change over time under the influence of a person, but cannot simply be thrown away. If management told developers that style doesn't matter (why would management care about such things is a different question), and one day would decide to enforce a single style, chances are concerned people won't welcome the decision, or the sudden way it is done.

Secondly, context matters. Not all code is the same. In the case I describe, asking to write quality code makes no sense whatsoever, because the code concerns a new, unstable feature being implemented right now: this is not production code, this is a prototype. The fact that source code for a prototype finds its way in the code base indicates a deep misunderstanding within the management people. This often leads to the “permanent prototype” syndrome I discussed earlier.

It's not surprising that developers are unwilling to put an effort in polishing code which will live for a few hours or mostly days, and then be replaced by something else. Then, when the code ends itself in code base in order to remain there for years, there is no frontier between prototype code and production code to encourage developers to start refactoring.

Thirdly, if developers are writing bad code, it means that something goes wrong at a larger scale within the company. Simply telling developers they should write good code from now doesn't solve the root cause, so instead, one should search the origin of the problem.

  • Is quality valued within the project? If developers are asked to ship features as fast as possible, only a fool would be surprised to see low work quality.

  • Are there proper measures to encourage good code quality? This may include positive reinforcement, automated checking such as PEP 8 compliance checks on commit, etc.

  • Do the developers have proper tools? Can they easily measure maintenance index or spot, through static analysis, the problematic parts?

  • Is code review regular enough? Is it done in a way people considering it as a mean to improve their code, or do they take it personally?

  • Is retrospection emphasizing enough on code quality? Are the proposals given during retrospection followed?

  • Is team communication established correctly? Are developers discussing code quality, constructively criticizing others and accepting critique from others? Are they hierarchically equal enough? Do they have time talking about code quality?

  • Are developers skillful enough? If not, the hiring process may be broken (and it usually is). Or maybe developers are hired correctly, but are rapidly losing their skills when working in the company? Are they trained enough?

When code base starts to rot, search for the root cause. Simply deciding that developers will write better code won't help. By clearly separating production code from prototype code and by finding and solving the root problem, one can indeed influence project culture and start to see the improvement in the quality of the code base.