Three Designing Bears

This post was inspired by a comment by Ron Jeffries that a little too much design up front is unlikely to be a big problem. That’s generally true, but less true in my development of JUnit Max than in my development of JUnit. I took a minute to reflect.

A little too little design up front or a little too little designing as you go is unlikely to be fatal to a project. Most software development (mine included) is so far from optimal that a little off of optimal is generally a big improvement. It doesn’t make sense to stress too much about the timing of design decisions before actually trying a new style. Time and experience will tell.

The cost of “a little too much design up front” is radically different in different business contexts, though. Two of the projects I work on are JUnit and JUnit Max. Despite the similarity in names, the two projects require completely different approaches to design. In JUnit, there is little competition, a large installed base, enormous market penetration, slow evolution of features, a high cost of changes that break APIs, and a large ecosystem of additional value (tools, training, knowledge, and skill). All this goes to reduce the cost of slow and careful design. Last week we added interceptors. This is a change that has been percolating for a couple of years. Taking that long to actually try something has no particular cost in JUnit. Getting it “right” (in the sense of unlikely to change) is more important than the speed of change. 

Switching to JUnit Max, the forces influencing design style are completely turned around. Max is a bootstrapped product, so I need to find revenue as quickly as possible. I have no idea what people might actually pay for in a testing tool, so I need to try things as quickly as possible. Features only need to be finished enough to give me reliable feedback about their value. Will people pay for features like those? If so, I can afford to finish them later.

Sometimes I get confused. I just added real-time collection of errors to Max. When an error occurs in actual use, the error log entry is sent to a server. I will analyze these errors to drive the rate to epsilon. My first vague design for this feature was fine–you get an error, open an HTTP connection, and send the data. On the receiving end, the servlet stores the error log data somewhere for later processing. So far, so good. Then I thought, “What I’d really like is a general error reporting mechanism. What if I had an extension point any plugin could extend with a URL to report its errors? Then I could use it, but so could anyone else.” I went ahead and tried to build the general mechanism. How hard could it be?

Three days later I had something general that worked. Pretty much. It still didn’t do exactly what I wanted but I could go live. Then I tried to deploy it. For various reasons that was error-prone and I wasted a couple more hours. Then I reminded myself, “What’s The Principle? Ship it and fix it.” So I tore out all the generality I had added, getting rid of 2/3 of the code. I radically simplified the server end–for the first day or two I don’t need a database, I could just write to the log file. Out it went. Hours later I started getting the first defect reports.

If I hadn’t taken that trip down Generality Lane, I could have been getting those defect reports Friday instead of Wednesday. The difference between Friday and Wednesday never ever matters with JUnit. It could matter a lot for JUnit Max. It could be the difference between nothing and a site license that funds development and turns into other site licenses.

The Principle for JUnit Max is ship it and fix it, but The Principle for JUnit is steady growth and low risk. Responsive design and everything that goes with it can help in both situations, but only if you keep in mind which situation you are in. It’s a balance. Someday I hope JUnit Max will benefit from a little more deliberation (I haven’t learned to value feedback over elegance). However, excessively valuing elegance over feedback leads to fat-and-happy stagnation.