Forget about Clean Code, let’s embrace Compassionate Code
When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others.
Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies. I often leave the office 1-2 hours later than my co-workers after polishing some piece of ultimately meaningless code. This is time I don’t spend with my family. Because I’ve learned to care about Clean Code.
Some of the most unpleasant experience in my professional life have been due to disagreements of the Clean way to write some piece of Code. I know people that I respect professionally that could have been good friends if one of us hadn’t insisted on purity of code in some situation or another.
And I’m not alone. I’ve seen teams that are at conflict with each other because of different expectations of a programmers obligations. Often fuelled by the idea of Clean Code.
As I’ve grown older, I learned to stop getting upset about “Unclean” Code. In any real world code base there will be an uncountable number of unfortunate quirks, odd and ends. This is okay. Things are the way they are because they got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because they wanted to go home to their family instead of sitting late in the office or if they just had a difference in opinion on what’s good code.
I sometimes train teams in TDD, incremental design, refactoring and pair programming. I almost always have to spend a lot of time helping the team bridge their disagreements in a more constructive way. And often the ones who have read Clean Code are the most susceptible to this sort of conflicts.
Why do I bring this up now? Because the reason that the idea of Clean Code is unhelpful as a guiding principle came in stark relief last weekend. The reason is simply this: We get led astray when we follow a principle or a rule without reflecting on what it does to ourselves and others. Robert (Uncle Bob) Martin is the author of the Clean Code book and a prominent developer trainer. He often writes on obligations, the oath to defend and preserve the honor of the profession, and shames excuses for not doing TDD. For a long time, there has been a nagging feeling at the back of my head about this language of “honor”, “obligation” and “professionalism”. But I enjoy test-driven development, and I have experienced it as a more fun way to develop. I believe that developers should reject illegal orders. I agree with Uncle Bob on all of these specific points.
Only when he writes something that I strongly disagree with, does the hunch about Clean Code became clear. The last days on Twitter we watched Uncle Bob implicitly decry the violation of Godwin’s law rather than the internment of thousand children under conditions that Amnesty International compare with torture. In the following days, Uncle Bob fought back against his critics also stressing that he thinks the situation is horrible, “but…” not as important as “unhonorably” comparing others to Nazis. I think his priorities are horribly wrong. I responded “In light of @unclebobmartin’s recent tweets, ideas like Clean Code have started creating a bad taste in my mouth. Let’s just say “code”, eh? I’m officially instituting “dirty code Monday’s” to remember to question dogma, tribalism and things-before-people mentality.” Bob asked me to explain “why you decided to lead a boycott against the concept of Clean Code”. Thus this blog post.
I deeply disagree with his stance on this political issue. I respect that some people value rules and principles higher than individual fates. I do not value rules for themselves. Bringing this back to code: I don’t believe we should use TDD because it’s a professional obligation. Instead I use TDD when it makes my work more enjoyable. I don’t think we should refactor our code because it violates a SOLID-principle. Instead I sometimes reach to a principle to understand why some piece of code is hard to change or understand. I don’t want to shame people for writing Unclean Code. Instead I believe in having an honest dialog among equals about how we want our code to look. I don’t believe that professionalism should compel us to introduce tests for all untested code. Instead I believe we should prioritize which deficiencies we fix and which code monsters we allow to live out their lives in their part of the code base.
I want to accept my unclean code as battle scars to be proud of and to be humble about, not as failings to be ashamed of.
My friend Thorbjørn Sigberg writes If your agile transformation has only one goal, it should be “Do less boring stuffâ€. When Clean Code becomes a source of less boring work, I’m for it. When it becomes a source of frustration and guilt, I’m against it.
For me, the ideas of Extreme Programming that bring the greatest joy to my professional life and that of my team are ideas about the whole team, about pair programming and about focusing on the users. Uncle Bob acknowledges these elements of the programming practice, but hardly ever talk about how to do it well. I don’t agree with these priorities.
As Uncle Bob nominated me as leader of “the boycott of clean code”, I guess I should try to end with something profound. How about this: Your most valuable skill is to know what’s important. Code is not important. Principles are not important. Rules are not important. People are important. That means your users, your team, your family, yourself. To quote Joshua Kerievsky’s Modern Agile: Make people Awesome. Clean Code may help or hurt that goal. Learn to see the difference.
