ZURB – Code Fisting

Code Fisting by Matt

March 02, 2009 in Implementation with 3 Comments

Code Fisting: A phrase made popular by Zed Shaw describing the act of committing large amounts of broken code, usually right before a deployment and not telling anyone (or not knowing) that the code is broken.

When you are a fistee (the person responsible for fixing the broken code) your natural reaction is to assign all blame to the fister. But there's a reason your code got fisted and it's not just because the fister was held back in the 3rd grade. Twice.

There once was a time before revision control. You worked on your local machine and at some point needed to deploy your code to a shared environment. This was a leap of faith since you had no idea what changes your teammates had made to the code since you checked it out. It was also a leap into a pit filled with angry snakes.

Then came CVS. A place to store all your code and get updates from others before making the leap of faith. However CVS was cumbersome and the common practice became (and still is in many places) to wait until the last possible moment to commit any changes. This minimizes the times you have to deal with CVS, but ensures your leap is still into a pit full of snakes.

The next evolution was Subversion. Learning from the mistakes of CVS it made commits and updates quick and painless. The new motto was "Commit often!" Unfortunately this coincided with the DRY movement, and its mottos "Refactor all the time!" and "Don't be afraid to make sweeping changes." Which brings us back to code fisting.

When you are not afraid to refactor, and you commit all the time, you're going to break shit. That's a fact.

Here are some solutions:

Have clear expectations about which branches must have rock solid code in them. Trunk or master for example.
Create a release or experimental branch for refactoring so you can test and share changes with other before merging them into trunk or master.
Use Git to make the previous two points as painless as possible.

Frequent commits and refactoring are good things. Some communication and management are required to prevent code fisting but it beats landing face first in a pit full of snakes.