Well Done Software

Not long ago, a friend told me about the excellent food at a frou-frou steakhouse that recently opened downtown. I tend to favor frugality, but he assured me the bacon-wrapped filet medallions were worth the second mortgage. My wife, Barbara, and I did a cost-benefit analysis and decided the budget could take the hit if we postponed our Branson vacation until next summer. I made dinner reservations for two.

I, for one, believe a steak done well is a steak well done. Many a waiter has reminded me this is atypical, so I was not surprised when I ordered my filet medallions well done, our waiter leaned in close, and whispered, “Are you sure?” I wanted to say, “Look pal, I’ve eaten enough steak to know I don’t like it bleeding all over my plate,” but Barbara has me conditioned to smile and nod confirmation.

At this point, our dining experience took a detour to the twilight zone. The chef himself burst through the kitchen doors and made a bee-line to our table. In no uncertain terms, he chided me for making him ruin a perfectly succulent cut of meat and urged me to reconsider my preferences. It seems his rigorous training, years of experience, and meticulous reading of trade journals made him better qualified to know how I wanted my steak. He only backed down when I threatened to take my vacation money elsewhere.

I stewed about the chef’s arrogance for days, and the incident was still fresh in my memory when I read this from Technology Review:

“Users are tremendously non-self-aware,” Myhrvold adds. At Microsoft, he says, corporate customers often demanded that the company simultaneously add new features and stop adding new features. “Literally, I’ve heard it in a single breath, a single sentence. ‘We’re not sure why we should upgrade to this new release-it has all this stuff we don’t want-and when are you going to put in these three things?’ And you say, ‘Whaaat?’” Myhrvold’s sardonic summary: “Software sucks because users demand it to.”

Myhrvold believes his rigorous training, years of experience, and meticulous reading of trade journals make him better qualified to know what users want in their software. Like the chef, Myhrvold thinks the end product is his and users should recognize their non-self-awareness and listen to the experts. In fact, software exists to fulfill users’ needs, not developers’.

My own sardonic summary: “Software sucks when developers demand it to.”

Dilly Bar Architecture

A few years back, my wife and I participated in a treasure hunt as part of a social event/fund raiser for an organization. One clue led us to the local Diary Queen where we had to tell the clerk behind the counter a password (derived from a previous clue), after which we were each given a Dilly Bar as our next clue. For those who don’t know, a Dilly Bar is the Dairy Queen version of an ice cream bar. After wracking our brains we eventually figured out we should eat the Dilly Bar. Sure enough, the next clue was written on the part of the stick that had been embedded in the ice cream.

I faced a similar scenario at work a couple of weeks ago. Our team uses Jakarta Commons Digester to read XML files and create objects based on the files’ contents. As part of a refactoring, I created an XML file and had to write code to process it. Having never used Digester, I looked to existing code for guidance. I was quickly left scratching my head (a common occurrence, I assure you). Most of my consternation was caused by several levels of indirection. Here’s the existing code, modified to protect the innocent, namely me.

String filename = MyPropertyUtil.getProperty(Constants.CONFIG);
File input = new File(filename);
filename = MyPropertyUtil.getProperty(Constants.DIGESTER);
File rules = new File(filename);
Digester digester = DigesterLoader.createDigester(rules.toURL());
MyClass mc = (MyClass) digester.parse(input);

Long on brevity, short on pithiness; I discerned what the code did quickly enough, but I had little idea how it did so. This in itself is not a Bad Thing, but the adumbrative structure unnecessarily obfuscated code. The major offender is embedded Digester method calls in a digester_rules.xml file. It’s a level of indirection that, in most cases, hinders maintenance and code comprehension. There is scant reason to hide code in allegorical ice cream.

Here’s a simple version of the digester_rules.xml processed by the code above:

<digester-rules>
    <pattern value=”*/node”
        <object-create-rule classname=”com.mycompany.MyClass” />
    </pattern>
</digester-rules>

Here’s what the code as written in a Java class would look like:

Digester digester = new Digester();
digester.addObjectCreate(“*/node”, “com.mycompany.MyClass”);
MyClass mc = (MyClass) digester.parse(new File(input));

If I were to do a rewrite (I won’t), I would change the existing code to look more like this:

MyClass mc = loadMyClass();
…
private final MyClass loadMyClass() {
    Digester d = new Digester();
    d.addObjectCreate(“*/node”, “com.mycompany.MyClass”);
    return (MyClass) digester.parse(new File(“config.xml”));
}

Yes, the file name is hard-coded. Code in loadMyClass() is specific to a certain file—it is not, nor should it be, generic. The roundabout method of using a constant as a key to a value in a .properties file might sometimes be useful, but not in this case. The file name is not going to change (if it did, that would justify the use of a property file) and it’s not likely to be used anywhere else in the system (if it was, that would justify the constant value).

Embedding code in XML is rarely a good idea. The search for clues is fun on a treasure hunt, but there’s no place for it in software development.