Green Coding - Taking Clean Code to the Next Level

When things change sufficiently their names should follow. Label and content should be in sync. Otherwise the label loses its usefulness. That's what the Single Responsibility Principle and refactoring are about. But it's true not only for code. It's also true for concepts and methods.

When Robert C. Martin wrote his book "Clean Code" in 2008 he put a label on a certain set of principles and practices. That was very valuable indeed. From then on developers were able to talk much easier about a particular aspect of software development. Evolvability - the quality behind Clean Code - was better to grasp and communicate to managers.

Since then, though, quite some time has passed. And as important as the building blocks of Clean Code are, they are not enough. As long as one focuses only on the content of "Clean Code" or "The Art of Readable Code" to improve evolvability, it's hard to go beyond a certain level. At least that's what we've been observing throughout the past 7 years since Stefan Lieser and I founded the Clean Code Developer initiative, which has become very popular among German speaking developers.

Something missing

Teaching SRPSLASoCISPOCPLoD etc. simply is not enough. It helps to improve awareness, it leads to better codebases. But still... something is missing.

There are tons of valuable, tried and true principles and practices in those books waiting to be applied. Take a look at the tables of contents. They are chock-full of stuff you should know (or at least have heard about ;-) ). What's lacking, though, is a framework to tie it all together. Yes, that's what we've found.

You can write down all those principles and practices on index cards and learn them. Great! Go ahead! And then of course apply them. But there's no story behind them. No narrative. No path to follow.

Certain "calls to action" like "Do TDD!" or "Do pair programming!" or "Do regular reviews!" describe activities (practices), but still don't tell a story.

That's strange, because there always is a story to tell in software development. It has a start, it has a (more or less clearly defined) end, it's full of dangers and moments of success. It's even a quest, I'd say. There are fellows and adversaries. There are unexpected turns of events. It's full of despair, and WTFs, but also joy.

There is a story we all follow again and again when we embark on a software project. In it we seek to please King Customer by finding the ultimately satisfying code. Today that's not just functional and efficient code, but also code which is clean. Our industry's contemporary version of a holy grail.

Despite all the principle and practices of great utility for a successful quest, there is no map for our path. We're not provided with a guideline, no handrails, no Ariadne's thread to follow from a customer's request to a satisfying codebase.

Try it for yourself. Here's a sample quest you can set out on, the CSV Viewer application kata. It's simple, but not trivial requirements. You're supposed to produce a small application. Now, how do you do that? Can you describe how you move forward? What do you do first, what second and so on? And most importantly: How do you ensure you´re writing Clean Code right from the beginning?

Confronted with this task many developers have a hard time to provide a straightforward answer. They are lacking a systematic approach to software development - despite all the OOP they've heard about, despite all the Agile processes they've heard about, despite all the Clean Code principles and practices they've heard about.

I call it "the fear of the blank flipchart" ;-) Because when asked to sketch their approach and/or their solution on a flipchart, they fear to draw anything on a blank flipchart sheet. What should they draw? Where to start? Use a diagram or text? That's a mystery to many, if not most developers.

And so they resort to the one thing they know best: textual code. Code in the IDE is concrete, it can be executed and thus checked if it's pointing in the right direction.

Of course RAD tools of all sorts are a godsent. Unfortunately, though, code is much harder to change than a thought or a diagram on paper. And communicating ideas through code is harder than with images.

That's why we think, what's lacking is a straightforward method to move from requirements to not only functional and efficient, but also Clean Code.

It should be easy to write Clean Code right from the start. Don't wait for some kind of review to fix your code. You can't test correctness into code. You can't review evolvability into code. Reviews will be skipped too easily. So better write Clean Code the first time.

Starting with Clean Code right is not a matter of code alone, however. It's also a matter of how you deal with requirements, and how you think about the solution before you write any code. Both aspects - requirements analysis as well as solution design - are not part of what has been subsumed under the title Clean Code so far, though. But they are as important to evolvability as is the SLA or good names or good formatting or good comments or unit tests.

Over time this has led us to the conclusion, Clean Code wasn't anymore an appropriate name for what's needed to really reach considerably higher levels of evolvability. But what else to call a method including Clean Code? "Clean Code 2.0"? We toyed with that idea but it never felt quite natural.

Green Coding

Then, the other day, it hit us. A customer of ours had written "Green Code" on a flipchart next to other building blocks of Clean Code. (Thanks, Guido!) "Green Code" immediately resonated with us. And after some thinking we settled on Green Coding. To us that sounds about right. It's a crips description of what we envison the next level of improving evolvability to be:

• "Green" - although a bit worn - denotes (even more) clearly the purpose of this kind of coding: sustainability. Software has to evolve to be of value not only today but indefinitely into the future. Customers who order a software don't put an expiration date on it. Also they don't tell you what kind of changes the software needs to undergo until it's taken out of operation. Thus software development has to move forward in a sustainable manner. Code is a resource which needs to be treated like a forest. You can't just do anything to it to satisfy short term requirements. "Green" has become synonymous for sustainability, but it's more striking.
• "Coding" instead of "Code" is supposed to emphasize the process instead of just a result. We need to talk more about what to do and when to do it in order to move forward from requirements to an evolvable codebase. Still it's the code the customer wants. But that should not just conform to certain principles, but also be produced in a manner making it more likely to be evolvable. We need to talk about behavior and ways of thinking. That's why we deem "Coding" more encompassing than "Code".

In the past years we've embellished Clean Code with principles and practices like IOSP/PoMO, spinning/shuffling, Informed TDD, data flow design, requirements slicing and more. A de facto new whole has emerged of which the original Clean Code building blocks are a part. But the new whole now deserves a name of its own. We think Green Coding is a good candidate for that. It puts content and label in sync again.

Stay tuned for elaboration of the details of this method... ;-)