The Cafes » Programming

There’s a philosophy in extreme programing circles that one should never break the build. As soon as the build is broken, everything stops until it can be fixed again.¹ Some teams even hand out “dunce caps” to a programmer who breaks the build.

If by “build” you simply mean the compile-link-package cycle, then I tend to agree. Breaking the build is pretty serious. One of the advantages of extreme programming is that the increments of work are so small that you don’t get very far before discovering you’ve broken the build, so it’s relatively easy to fix. Integration is almost automatic rather than a painful, months long process. Avoiding coupling is also important to keep build times manageable.

However some systems define the build a little more broadly. They consider the build to include successful execution of all the unit tests. For example, Maven gives up if any unit test fails.^* It will not create any subsequent targets such as a JAR file, if it can’t run unit tests. Ant doesn’t require this, but does allow this. All that’s necessary is declaring that the jar or zip target depends on the test target.

It’s not just open source either. Over at closed source vendor Atlassian, Charles Miller tells us, “all our tools are predicated on tests that start green and stay green. ” In fact, a failing test is so damaging to them, that he actually advocates writing tests that pass if the bug isn’t fixed and fails if it is. That’s a recipe for disaster if I ever heard one. Five years down the line some new programmer is going to finally fix the line of code that causes the bug, and then carefully reintroduce the bug to get back to the green bar.

This is where I part company from the most extreme of the extremists. If building includes passing all unit tests, then it is often acceptable and even desirable to break the build.
(more…)

No this isn’t another rant about agile programming or test-driven development or test first programming. There’s a depressing phenomenon in some open source projects (including Jaxen and PHP) where a programmer goes off in a corner, gets a cool idea, writes it up, contributes it, has it checked in, ships it to millions of users; one of whom has the distinct pleasure of being the first to ever actually use this code.

I am getting really tired of discovering code that is broken by design; not merely buggy but partially to completely non-functional and unable to be fixed. The worst case I ever saw was in Jaxen where I once spent two days trying to write unit tests for a package that had been contributed years ago (without any tests of course) and banging my head against the wall trying to figure out how to reach that code. Only after this time, did careful analysis of code paths reveal that the code could never be reached, no matter what. It never could have been reached.
(more…)

The Xerces XML parser recently localized its error messages, which seems like a nice thing to do. However sometimes good actions have unintended consequences. It turns out the localized error messages are a lot harder to find with Google than the English ones. Paste an English exception message into Google, and you’ll probably find 10 people who have already had and solved your problem. But the same message in Greek or Croatian? Maybe not.
(more…)

Over long distances, airplanes are the fastest way to travel (at least until we invent teleportation) but over short distances that isn’t true. If you want to get from La Guardia Airport to O’Hare, take a plane; but if you want to go from La Guardia to JFK, take a cab. Over shorter distances still, a bicycle may beat a car; and over the shortest distances, the fastest way to get somewhere is usually walking. Terry Pratchett explained it well in Interesting Times:

Of the three things that most people know about the horse, the third is that over a short distance, it can’t run as fast as a man. As Rincewind had learned to his advantage, it has more legs to sort out.

You naturally choose your mode of transport according to the distance you plan to travel. A few hundred meters or less, walk. A kilometer or two, take a horse (or more likely these days, a bicycle). 10K to a few hundred kilometers, take a car. And beyond a few hundred kilometers, airplane is the fastest choice; and the longer the journey the better a choice it becomes.

Programming is much the same. (more…)

I’m doing a little hacking on jEdit in preparation for my next article, as well as an upcoming talk at Software Development 2006. After mutliple failed attempts, I finally figure out how to check out the main code base from CVS into Eclipse with assistance from Rick Stabile.

The next step is to run the main() method. The application starts but no window pops up, and this error message is printed on the console:

[error] Image Fetcher 0: Uncaught error fetching image:
 (more…)