Summary
The other day, I wrote a little testing tool for Java. It’s a simple little thing, just a set of classes that you can use with JUnit to make refactoring a little easier. When I was done, I looked at it and I realized that I’d made a bit of a mistake. I wrote the tool using Java 5.

The other day, I wrote a little testing tool for Java. It’s a simple little thing, just a set of classes that you can use with JUnit to make refactoring a little easier. When I was done, I looked at it and I realized that I’d made a bit of a mistake. I wrote the tool using Java 5.

Sure, using Java 5 made my life easier; I was able to use generics and a couple of other cool features, but it didn’t look like it would make things much better for users. Not everyone is using Java 5. Many of the teams that I visit now are stuck using 1.4.2 and occasionally, I visit some who (gasp, shudder) are using 1.3.1.

So, what did I do? Well, I backported the tool to 1.4.2 and I may yet move it back to 1.3.1.

I’ve done this sort of thing before. Early on, I did a port of JUnit to C++. Immediately, I was inundated with email from people who were stuck using some earlier version of C++ and they each had a laundry list of features that their compiler didn’t support. What did I do? I wrote another testing framework and tried to make it adhere to the earliest widespread standard in C++, the language as it was defined in the Annotated Reference Manual back in 1990.

Now, I did both of these backports nearly reflexively, without thinking about it. I recognize, though, that this is almost exactly the opposite of what many people do when they write tools and frameworks. Often what they do is target their software for the latest version of the language. Sometimes they hang back a little and write to the last version until the newest one takes off, but most of the time, they target the latest and greatest.

Do they do it consciously? I know that they do sometimes. The theory goes like this: “If I use Java 5 or TR1 features in C++ (or whatever); it’s progress. I’ll create a pull that will get more people to upgrade to the latest and greatest version of the language.” That’s fine as far as it goes, but it doesn’t do much for the people who for one reason or another can’t upgrade.

People who believe in the “pull theory” might consider what I’m doing a moral hazard, but for tools which are designed specifically to help people in hard circumstances, I think it’s the right thing to do. Aside from that it’s fun. There’s a weird kick you can get from trying to do something in a reduced subset of a language. It presents some interesting design challenges. Sometimes, you actually end up with simpler software.

Talk Back!

Have an opinion? Readers have already posted 5 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.