Discontinuous Integration

Refactoring is becoming a commonplace term thrown around these days. The expectation is building that refactoring is something that all good developers do and if you don't, you must be in one of "those" types of companies. You know the ones, they don't use a version control system or have a repeatable build, i.e. Continuous Integration, much less a well-defined deployment procedure.

If you are lucky enough to be building the first version of a product, you can refactor to your hearts content. There is no existing code to worry about breaking. If you are changing an existing system refactoring isn't always simple or straightforward. Even if you have the most automated CI and 100% code coverage of unit tests you'll still face the practical issues of deployment and business dependencies.

Let's say you operated the worlds most modern airline reservation system. It's written in the latest language and has all the buzzwords, highly available, highly reliable, highly scalable, etc. It has tons of automated tests so you are 100% confident that nothing will break. Now, since you have business partners like travel agencies and customers looking to book a flight or retrieve flight information, they have a stake in your deployment. The customers may tolerage a "Down for maintenencem, come back later." message but your partners will take a dim view of your downtime. They'll insist you tell them in advance so they can prepare any necessary changes in their systems or alert their support staff in case there are issues after the deployment.

Another example would be a large back-office accounting system. Whatever level of confidence you have in your code. you still have to deal with the myriad inputs and outputs of the system and disrupting the processing schedule for a code migration. No amount of automated testing/build/migration will ever solve these types of complexities.

The point is that considerations like these limit the opportunities to deploy code changes and increase the cost of change even when that change is guaranteed to work.

Refactoring is good but there are practical considerations why it's not done to the degree it could be in some shops. Keep that in mind next time you want to pass judgement on the perceived lack of refactoring somewhere.

Blood, Sweat, and Tears

Showing a fellow developer how to create JUnit tests for Java code, I came up with a saying. "Refactoring is a whetstone with which you can hone your design skills." Maybe I can come up with another good phrase that includes unit testing.

Being a Codewright is like being a blacksmith. While casting something in iron is relatively straightforward, it also requires much more prior planning. It also assumes that we want to make copies of an existing design. Anything custom means pounding it out by hand the hard way.

With much sweat and toil in the crucible of coding, we put code into the forge of the code review to make it malleable, we use unit tests like an anvil to support our efforts as we bring to bear the hammer of refactoring to shape the code to our will all the while evaluating how much work is needed to achieve the desired design.

So, when you hear your team banging away at the code ask yourself, is the noise they're making that of peices being moved around with fervent hope that "maybe *this* will work!" or are they methodically improving the code through the use of the forge, hammer, and anvil?

The Age of the Design Review

Is programming an art or a science? That question has been asked for many decades and it will probably be asked for many decades to come. We've been searching for the construction equivalent of standardized parts like screws, nuts, bolts with which to construct software. We've treated coding languages and code libraries like silver-bullets and have been disappointed every time.

My question, is Software Engineering showing signs of maturity? In a post named "Leaky Abstractions and the Last Responsible Moment for Design" Jeremy Miller gives a good example of looking at a design and reviewing it.

I believe that we are seeing the beginnings of the common language needed to really improve the ability of practitioners to objectively discuss, evaluate, and correct the designs of others. One solution that is often suggested is to perform code reviews, which assumes that code standards have been put in place. Code reviews are nice but they usually come in two flavors, either examining the syntax or the design. Syntax reviews can be simple 'proper use of braces' to more detailed like patterns for using virtual destructors. There is a limit to syntax reviews because the code has already been written, like shutting the barn door after the horse has already escaped. What is frequently mentioned is the need for a design review which has been the holy grail. How do you do that without a common language? Design reviews no longer seem beyond our grasp. I've seen plenty of stories where time after time, software injuries are self-inflicted by Code Monkeys and Cowboy Programmers. Design reviews might not create world peace or feed the hungry but it might make it easier to keep apprentices or journeymen from masquerading as master craftsmen.

Between Anti-Patterns, Code Smells, and Refactorings I have the impression that the industry is reaching a point where we have the tools to properly review and critique software designs consistently. A common set of terms for describing and understanding problems; a common set of tools for describing and implementing solutions.