There’s an awful lot of sound and fury right now about adding syntax support for properties to Java 7. The more I think about this the more I think the whole idea is wrong for several reasons:
Read the rest of this entry »
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.1 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.
Read the rest of this entry »
John C. Welch has a nice article in Information Week in which he compares Mac OS X to Vista, and Vista comes out much the loser. This is no great surprise, especially since he focuses on UI issues. This is like comparing a Toyota Camry to a car built by UNM engineering students for the Formula Society of Automotive Engineers competition. Sure, it’s cool that the undergrads can build a car in a couple of semesters, but you wouldn’t put the student car in your driveway to commute to work.
However, what struck me was how many of Welch’s examples of how things were easier on Mac OS X, were easier only by comparison to the even poorer Vista. Many of his examples are actions that non-geeks are not able to accomplish on Mac OS X. They are harder than they need to be be, and harder than they should be. For example,
Read the rest of this entry »
Recently I decided it might be easier to install a recent libxml on Linux rather than try to figure out how to get one on the Mac. I’d forgotten my password for the Linux box I hadn’t turned on in about half a year, and I didn’t seem to have it written down anywhere, so I decided I might as well upgrade. Linux is clearly improving, but is equally clearly not ready for an end user yet. If you like compiling and installing libxml from scratch, Linux is for you. If, on the other hand, “compiling and installing libxml from scratch” is unintelligible techie gibberish, it’s not.
Read the rest of this entry »
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.
Read the rest of this entry »
