One of the things most Agilists harp on is the need for Clean Code: Code that can be easily extended and maintained, and that Coders shouldn’t be afraid to work with. But, what does this really mean? To answer this question, I turn to some of the best Coders who ever lived:

1. ‘Uncle’ Bob Martin: “Code, without tests, is not clean. No matter how elegant it is, no matter how readable and accessible, if it hath not tests, it be unclean.”
2. Ron Jeffries: “Clean Code Contains no duplication and expresses all the design ideas that are in the system.”
3. ‘Big’ Dave Thomas: “Clean code can be read and enhanced, by a developer other than its original author.”
4. Michael Feathers: “Clean code always looks like it was written by someone who cares.”

I could go on and on with these quotes, but I won’t. Let me simply make the following definition: “Clean Code is Code that is Protected by Tests, Well-Structured, and Readable.” I’m not going to differentiate between different kinds of Tests, define what “Well-Structured” means, or try to describe what make Code “Readable.” I’m keeping this simple, and simply saying that, when it comes to Code …

3Back Clean Code

Clean = Protected + Well-Structured + Readable.

UnClean Code is Code that fails any of these three conditions. If it fails all three of these conditions (it is UnProtected, Ill-Structured, and UnReadable), then I call it Ugly Code, and many of you have some Ugly Code sitting around somewhere… just sayin’…

Code that is not Clean is said to have Technical Debt, which is the debt you “owe the Code” to make it Clean — The definitions of Clean Code and Technical Debt are tightly coupled. Sometimes we create new Technical Debt, and sometimes we find existing Technical Debt; in either case, we want to Clean it up as soon as we can… Technical Debt is like a PayDay Loan; if you don’t pay it back real fast it will eat you alive; the interest on the Debt will kill you.

So, what does it take to Clean up Technical Debt? To keep it simple, let’s just consider the case of Ugly Code, which has nothing going for it. In this case, we will need to Protect the Code with Tests and Repair it to make it Readable and improve its Structure. In other words, for Ugly Code,

3Back Clean Code CleanUp

CleanUp = Protect + Repair.

In general, CleanUp activities can be doing one or both of these things, depending on just how UnClean the Code is. The most common kind of Repair is doing Refactoring, but we can’t Refactor the Code until we have Tests Protecting the Code… the most important thing is those Tests! (Note: I know that many of us — me included — have been using the word “Refactor” as a synonym for “CleanUp” (and vice versa), but it’s wrong and confusing. So, let’s just stop that now, whaddya say…)

So, if you have UnProtected Code, you need to Protect it with (automated) Tests before you do anything else. Unfortunately, Protecting Code with Tests is difficult and expensive, especially if the Code is Ugly. You’ll have to do Exploratory Testing to figure out what the Code is actually doing, and then figure out a way to automate Regression Tests to Protect it. One way to do this is with explicit, Time-Boxed, CleanUp (Protect the Code) Stories in the Backlog, focusing on one Feature at a time.

On the other hand, if you have Protected Code, life is easier. You can simply do incremental Refactoring as part of all your Functional Stories, and clean up the Code a little at a time. But this does require existing automated tests…

So, do you have Clean Code? If not, what are you going to do about your Technical Debt?

Tagged with →  

2 Responses to Clean Code, Ugly Code, Technical Debt and CleanUp Stories

  1. MichaelRWolf says:

    “UnProtected Code” — What a simple idea that I already knew!  (But hadn’t put into those words).  Yeah.  That makes sense. The extra code that we write is about protection, but just happens to be called a test.  Perhaps we should start calling them protections instead of tests — as in…
    * The new module has150 automated protections
     * We follow a PDD (Protection-driven development) process 

     * Is that code well protected?  
     * How well protected should code be before it’s delivered?

    This leap of language should have occurred to me a decade ago, as I often compare having tests for code to having protection on a climbing route.  Yes, we call the nuts, webbing, chocks, and various hardware by the term “protection”… as in “Do you have enough protection on that route to try the new move you’re attempting, given it’s degree of difficulty, risk of failure, and cost of failure?”  If it’s a simple move, or the cost of falling isn’t great, you don’t need as many pieces of protection.

    The analogy to climbing is, and always has been for me, a very obvious one.  But I haven’t thought about replacing the word “test” with “protection”… until now.

    Thanks for the reframing.

    And… now for another variant in the xDD world — Welcome to Protection-Driven Development – PDD!

  2. MichaelRWolf You’re welcome…

Leave a Reply

Your email address will not be published. Required fields are marked *