The million dollar question every software developer asks themselves is:
How clean is this code?
As outlined in the Agile Manifesto, an essential principle to ensure successful agile development is the standard that, “Business people and developers must work together daily throughout the project.” With that said, the primary goal of clean code is to reduce the friction between the business user and the software writer. Often times developers are under the impression that they’ve reached their end goal if the application operates, but Agile is about face-to-face conversation not computer consumption. If the code is not comprehendible to all other parties, this will further the divide between the business user and the software writer.
Clean code is a foundational tool for agile software craftsmanship. Bob Martin said it best: "Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.”
One of the problems with clean code is that it can be difficult to define. Determining when we've gone from cleaning a good thing to polishing a thing of limited business value is challenging. We've all been in THAT code review with THAT teammate who makes Mr. Monk look completely reasonable.
I'm always looking for examples of clean code to use as illustrations. I came across this image and it is a perfect representation of what it means to write clean code that is not highly polished.
You may ask how I know this is clean and not highly polished code? I know this is clean code because my wife - who is not a programmer, scripter, function or macro writer, but a fan of pop music from the 1980’s - was able to read the correct song title from this code in just a minute or two. That is the equivalent of the non-programming BA (or product owner) looking at your code and saying, "Yep, that's what I meant." Could another developer come into this code, and listening to the business person, figure out what to change if it now matters when the wind blows from the North? I submit, yes!
In addressing the polished question, I do not think this is over-polished. I think if it were, the prose might read a bit more plainly. This code is sufficient, but not something Mr. Monk would look at and say "nothing to straighten here.”
I haven't always written clean code. In fact, sometimes I still don't. The difference between my senior developer days and my junior developer days is that I now recognize when I'm not writing clean code. I know that clean code is something I should always strive for, and I shouldn't accept less from myself. At the end of the day, when you're looking at code - yours, someone else's, mine - and you're trying to determine if it’s clean enough, grab your business person and have them read it. If they start humming the correct tune, you'll know you're close.
How clean is your code?
Do you feel that having clean code is helpful from a business perspective? Feel free to share your thoughts with us below or connect with someone on our team to collaborate on best practices. Reach out to agileinfo@eliassen.com for more information. #cleanupyourcode
