Agile Otter Blog

Balance these facts: Refactoring is a good thing, but is also perturbation. Gratuitous perturbation is a bad thing. Refactoring is good because confusing, stupid, repetitive, complicated code is the devil. We can't even pretend it is not the devil, because we catch bad code sneaking away with a slice of our souls from time to time. Bad code is bad. Refactoring makes bad code better. Some perturbation is a very good thing. Gratuitous perturbation of the code base is a bad thing. If I make a million changes to a million places, then diffing (and therefore merging) are going to be a slice of hell. This is a different devil, but still a devil. The problem with perturbation is that it makes it hard to maintain branches. Branched development is a good thing sometimes, providing some isolation for a very short period of time, and some ability to compose and recompose a release. Branching becomes odious, however, when the code in a branch differs greatly from the code in a shared c...

Branching is a coping mechanism. There is a lot of branching and release-time cherry-picking of features in the commercial software world. It seems to alleviate some pain and make the process more manageable, but I fear this is at too great a cost. Many development groups branch due to dysfunction. Note that I am not talking about open source projects. I'm specifically speaking about commercial projects where programming talent is not free. I'm also not talking down distributed version control, where every checkout is really a separate branch. I am concerned more about use of branches for the wrong reasons and at a high cost. Often branching is used to put off integration. This is a losing game. After so many changes to the trunk a branch will no longer slide seamlessly into the release stream. We can work around that problem (itself a work-around) if we merge forward all branches periodically so that they track the trunk more closely. This activity is time spent on featu...