How to motivate developers to care about code quality

August 29, 2019


Technical Difficulty

Reading time

It’s now widely accepted that a low technical debt is always desirable, because paying high interests impacts your capacity to add new features to your product. Still, the practices of continuous refactoring, and technical debt control, are not that widely applied. While there are recurrent complaints that managers don’t allocate proper time to pay the debt, I think there is also a lack of personal motivation.

During the past 15 years, I’ve been managing development teams, or coaching teams to adopt eXtreme Programming. And most of the time, it was on legacy code. Continuous refactoring was crucial then. But it was always very difficult to include it into the team’s routine. As a manager and a coach, I consistently stressed the benefits of refactoring and set up an appraisal system that put code health improvements at the same level as new features. It was not enough to motivate the developers. Because they still had this additional satisfaction when adding a new feature that they didn’t have with refactoring.

So what could you do to motivate your team?

Fear is a great motivator, but …

Most software developers have heard about this famous sentence, from the C2 wiki:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

Having found myself frequently drowning in unmaintainable code written by others, and ranting about it, I can easily imagine dozens of other developers just doing the same about some of my code. You know, the one you write to deliver this late feature your client is waiting for, with the usual TODO: Add tests, TODO: Refactor this or FIXME: Duplicate, and that never actually gets done or fixed.

It’s pretty clear that under the threat that one angry developer could find me and exercize a rightful (but violent) retaliation, I’d certainly think about it twice. Fear is a great motivator. Our fear of the great predators has been quite effective at keeping us humans alive, as a species. And it’s no secret that a very big number of features are “finished” (with TODOs) on time under the pressure and threats of a frustrated client.

However this motivation obviously doesn’t work very well in our context, given that our profession doesn’t seem to be very attractive to psychopaths.

Isn’t L.O.V.E. a better incentive?

In the same C2 wiki, right after the previous sentence, there is an alternative proposal:

Alternatively, always code and comment in such a way that if someone a few notches junior picks up the code, they will take pleasure in reading and learning from it.

No one remembers this one, certainly because it’s not as funny as the former.

The two alternatives could not be more different. You cannot reconcile the images of a younger colleague learning from your legacy with pleasure, with the one of a psychopath giving free rein to his torturing taste on you. So you have to choose one incentive. And I claim that the positive one is much more effective. Why?

Because Robert Mitchum says so. In “The night of the Hunter”, he tells the story of the fight between his tattooed hands:

It's L.O.V.E. that's won, and old left hand H.A.T.E. is down for the count!.

Robert Mitchum in The night of the hunter - 1955, Charles Laughton

Because handing your code over to enthusiastic juniors is much more likely to happen than handing it over to psychopaths.

Because management by fear hinders innovation and risk taking… which is pretty bad for a software developer.

Let’s try: :thumbsup:

Isn’t it a better motivation to know that people will like what you wrote? Of course it is! How good do I feel when people “like” my tweets or my posts! I feel somewhat addicted to these, and I know that if I don’t get enough likes on this article, I will right away post some funny cat memes, and invariably receive lots of likes that will cheer me up. (No, I’m not threatening you with a lolcats invasion… just kidding.)

What if the maintainer(s) of your code could “thumbs up” your code and your commits? What if they could rate your project?

Well, this is already happening to some extent in the open source world. On, developers can “Star” the project they like. They star the projects that they enjoyed using, or reading, or contributing to. It’s one appreciation for the whole project, not for the specific portion you might have written, but still, it’s already a great satisfaction to contribute to a popular project!

Let’s ask source control systems for a new feature: Coders can add a “like” if they enjoyed the code they worked on: git commit --like, for example. By doing this, all previous and current authors of this code will get the satisfaction they deserve!

What can you do now?

You can try and discover the emotions of the authors at the time they committed a piece of code. Albert Ziegler explains in his post about emotions in commit messages how you can classify a developer’s emotions according to the commit message. Presumably, the author will have different emotions after having patched ugly code or having contributed to beautiful code, and this will leak into the commit message. But these emotions can also be driven by external factors, and not only by the beauty of the code. The developer could have been irritated earlier by a discourteous neighbour, or cheered up by some good news in his newsfeed.

You can emulate the new feature above by asking your contributors to add a :thumbsup: or a :heart: at the end of their commit message. That is, if they liked the code, of course. But make sure to implement a commit checker to catch any non-acceptable :keyword:, as the inevitable :angry: and :poop: will certainly show up sooner or later. And you don’t want this sort of negativity to leak into your next release note.

You can measure the code health. In his blog post, backed by an extensive analysis of tens of thousands of open source projects, Jean Helie proves that code health—as measured by the number of alerts detected by LGTM analysis—and the popularity of a project—as measured by the number of stars on— are highly correlated.

On average, more popular projects have a higher code quality score

It means that if your code has a very good health, then you can be sure that users, readers and contributors enjoyed it. This is great news! By keeping the number of code health alerts low, not only do the coders get an obvious quantitative reward, but they also get a qualitative reward, because they know that readers liked their code, without even needing them to say so. LGTM helps you with that: with a project showing both a decreasing number of alerts, and a good quality grade, you give your team an incentive to continuously improve the code.

How to do this?

Just install the free LGTM app on your GitHub repositories:

Note: Post originally published on on October 2, 2018