Agile Otter Blog

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea. Here's what I say: Never pull from a broken build . Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem. Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way. Never push to the CI server if your local build is broken . If your build is broken, it inconveniences...

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...

This week, and last, we are doing our work in the release candidate (RC) branch, which will eventually be merged to trunk. We maintain a "stable trunk" system, with the RC as our codeline (for now). This is an intermediate step on our way to continuous integration. Partly because of the change in version control, the team has learned to rely more upon the tests, and is writing them quickly. We have had a noticeable increase in both unit tests (UTs) and automated user acceptance tests (UATs) in only one week There were some problems with people checking in code for which some tests did not pass, but they have learned very quickly that this is quite unwelcome. We are painfully aware of the time it takes to run both test suites. The UTs suffer from a common testability problem, in that they were written to use the database and they sometimes tend to be subsystem tests rather than truly unit tests. When they are scoped down and mocking is applied, they should be much faster...

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...