Code is an odd thing, it can be beautiful, ugly, horrible, elegant, it can smell - some people even compare code to poetry. If you are a developer, you will know that there are an almost infinite number of ways that you can write a piece of code with the same functionality. The way chosen will affect the different qualities that the code - and thus the program as a whole - will exhibit. These qualities are things like performance, testability, robustness, security, scalability etc.

However, when developers talk about code quality (at least when I do) the main focus is often maintainability and flexibility. From my point of view, any software project is always decaying, especially if you have multiple people working on it, hacks are made, designs are twisted into fulfilling new responsibilities that their original creator didn't foresee or intend. Even with a clean design and a focus on maintaining high quality, the amount of code is almost always increasing with new functionality, as is the programs complexity. This is sometimes known as software entropy - chaos. If this entropy is ignored over longer periods of time, the technical debt incurred will keep increasing until the interest is so high that the project will grind to a halt - creating new features takes a long time and introduces many new and interesting bugs.

Maintainability is important on most projects, it often depends on the complexity of the program and the expected lifetime - so if you are doing prototypes or mock-ups, focusing on maintainability may not be beneficial, although in my experience, when management sees a really cool prototype, they often feel like building a project on top of it. Most software projects will have a rather long lifetime, often with multiple versions and a need to maintain the project even after it has shipped.

Obtaining high code quality is a craft, it requires discipline and continuous refactoring and improvement. This will be the main topic of my blog for a while, save the random posts about ReSharper or other intriguing things that may come up. Topics within this field off the top of my head: Unit testing, design principles (SOLID and others), design patterns, understanding and taming dependencies, inversion of control containers, simplicity and many more - ideas are welcome.

I was out dining today and had an experience I simply had to share.  It was a moderately expensive restaurant and they had cocktails as part of their menu.

As my after dinner cocktail, I chose a Mojito, which is actually a fairly difficult cocktail to make properly - at least if you want it to be as strong as it ought to be, while still masking the taste with the proper levels of sugar and mint.

I watched as the bartender mixed the drink - he didn't measure, but he was focused on the task at hand - he even tasted the drink elegantly with a straw to check its quality. The Mojito was extraordinary - perfect - it was so good that I felt like I really needed to order another one. However, this time, a girl, clearly an apprentice bartender wanted to make my next drink. She used the same ingredients but her focus was all around, she didn't sample the drink, just mixed everything approximately as she had been told. Watching the process, I wasn't surprised when the drink was a disappointment - it was too sweet and kind of watery.

As I asked for the bill, at the first bartender, I complimented his craftsmanship and mentioned that the second Mojito had not quite been what his had been - he immediately cut the cost of the second drink in half. He didn't even blink.

What kind of bartender do you want to be?

I was catching up on my blog reading (ObjectMentor to be more specific) when I found Uncle Bob's post on quintessence as the fifth element for the Agile Manifesto. His statement of "Craftsmanship over Crap" really rang true with me.

We (software developers) like to compare our work to that of craftsmen and many people are starting to realize that maintainability is one of the cornerstones of writing good software. However, our software still keeps decaying, brilliant designs are mangled with hacks, quick bug fixes or just plain outdated with changing requirements.

However, I challenge you, next time you go to fix that bug or that small change request that almost fits the current design, step back and think first. Spend those extra minutes considering if there is a way you can fix it, maybe even improving the current design. Don't go on an overengineering spree, just keep it simple and elegant. Then, when you're done, sit back and marvel at your work and smile.

We've all made a quick hack, we will all do it again, but I promise you, those few extra minutes spent will be worth it in the long run. Technical debt has high interests. How often have you made a quick change while thinking (or even better made a comment) that you will come back and fix it later. How often have you forgotten?

Actively thinking about this and being proud of the results is really good for my personal productivity. Ideally, if you always leave your code slightly better than you found it, it should resist decay very well. Challenge your team to join you in this quest.

- Leave the code slightly better than you found it.

- Write a regression test for a bug, so it's not reintroduced.

- Don't live in a house with broken windows.

- Write tests to gain the confidence to perform refactoring.

- Be a craftsman.

And to quote J.P Boodhoo: 'Develop with Passion'.