You are what you code

This is the text of an email I sent last week to Fluid engineering. I wanted to remind and encourage our engineers to do the right thing.
 
We've all heard "you are what you eat" and we know its true...if not, just eat a diet of junk food for a month and check back with us.

Likewise you are what you code. If you are coding junk then you're a junk coder.

The fact that you're under a crazy deadline, or someones out sick or the dog ate the homework is a dangerous excuse because challenges like those almost always exist. 

The more you practice and apply junk coding, then that becomes how you develop software. That becomes your practice.

I've learned the more I practice and apply the best practices of software development the easier and the more natural it becomes (thankfully I've been lucky to work with some good role models to lead the way and help me improve).

One such best practice is refactoring code. 

I've learned the practice of refactoring code is very important. Code is not static nor sacrosanct, its living breathing and changing as requirements etc change (and requirements always change).

Refactoring code is part of my practice as a developer. I see no difference between refactoring and coding. There's all part of the one. This may be difficult for non software developers to grasp (and that needs to change) but it should not be difficult for a software developer to grasp (if it is then it's time to hit the books).

Uncle Bob says it well: "The goal of refactoring, is to clean your code every day, every hour, and every minute. We don’t want the mess to build."

With more projects and more deadlines and more new people, the temptation is to code junk, to take shortcuts, to allow the mess to build etc. will be strong.

Resist that.

We are the software experts on Fluid projects. If you need to refactor code to make it better then you should do so. 

I believe as software developers that one of our prime directives is code quality.

Budget and schedule is one of a PMs prime directives. We should be careful not to compromise/confuse our prime directives with others (and trust me, I know that's not always easy)

One caveat: when I talk refactoring I am generally talked about smaller changes. I did a major refactor of the whole Benefit Cosmetics Checkout into a state machine a couple of years ago but I've found in my work those large refactors are rare and often should/can/are projects in of themselves. The refactoring I'm talking about is often more of is smaller stuff like adding removing methods, classes, templates etc...even just adding comments when I learn more about the code.

Martin Fowler is an example of a good resource for this: http://www.refactoring.com/

Writing tests for your code goes hand in hand with refactoring and code quality. But that's an email for another day.