John Reynolds's Blog

January 2007 Archives

The Twin Paradox

My friend King sent me a link to this wonderfully perverse anecdote about how an insurance company was unable to handle twins: Disjoint Twins - The Daily WTF

To make a short story shorter:

"It turns out that a new version of their software was installed that tracked each person's budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two's budget, risking a premature budget exhaustion. "

Programmers don't dictate requirements... and in many shops they are even discouraged from questioning any requirements... but this anecdote points out something pervasively wrong.

My guess is that the technical aspects of the problem overwhelmed the practical aspects of the problem. Dealing with large numbers of users and high transaction rates consumed the intellectual bandwidth of the development and testing team.

Fear of the Unseen...

Many problems that businesses have with software seem to involve visibility. The role that specific software components play within an organization are often hidden, obscured, or just plain forgotten.

I have been in shops where software has been reliably clunking along for 20 years... faithfully executing night after night, 7 days a week, 52 weeks a year... for decades. Undoubtably, this software "keeps on ticking" because it is doing something useful for the business... but I also suspect that some of the things that the software is doing may no longer be necessary. In many IT shops there is a distinct "If it ain't broke don't fix it" mentality, and if you aren't sure you just leave things as they are.

My friend Si told me a story about an accounting package that was written many years ago (in the early 1960's) for a machine that has long since become extinct. Rather than rewrite the package when the company upgraded their hardware to the next generation, an emulator for the original hardware was obtained . Years later, when the company upgraded their hardware once again, they continued to run the package, on an emulator for the 2nd generation hardware that ran an emulator for the original hardware.

Si swears that this is a true story... and given the conservatism of a lot of organizations I have no reason to doubt him.

This anecdote relates an extreme case, but I doubt that it is unique. We keep doing things not just because we've always done them, but because we can't always "see" what's really going on. In general, we know what a package does, but we can't see its side effects and interactions with other software package. "Something else" may rely on our package, and there is no real way to know what will happen except to shut down our package and wait to see what happens. That's a scary proposition in a production environment.

Going back to Si's anecdote, continuing to use the legacy accounting package could be held up as a poster-child for software reuse. Did it really matter that the implementation details of the package were unknown as long as the package continued to perform as advertised?

Sound object-oriented engineering principles encourage "hiding things". Hiding implementation details behind published interfaces is essential when building any non-trivial system... When building the system, you really don't need to know how a function is implemented, you just want it to work as advertised... and apparently Si's accounting package did just that.

But my gut tells me that something's not quite right. We don't decouple implementation from interface solely for the benefit of those who consume our software... Interfaces are meant to benefit both parties. Our consumers don't have to worry if the implementation changes, and we don't have to worry about changing the implementation.

In Si's anecdote, the accounting package survived due to fear. Nobody understood the original code, so everybody was afraid to touch it. In a real sense the implementation was hidden (since it was written in an extinct assembly language).

I think we've got a visibility paradox. We need to hide implementation details behind interfaces, but at other times we need to know those very same implementation details.

Our challenge is to have it both ways. An application should never rely on the implementation details of its components... but we must be able to delve into those implementation details when necessary. When we need to upgrade hardware or operating systems, or when we need to diagnose and resolve performance issues, we need to know the details... or we may be forced into bizarre solutions like the one Si relates.

Kitchens and Fast Food Factories

Recently I've begun thinking that a Kitchen vs. Fast Food Factory analogy might teach us a bit about writing better software...

I'm always looking for good analogies: A good analogy is worth 1000 pictures (and since a picture is worth 1000 words, analogies must be worth a million words).

Kitchens and Fast Food Factories (like MacDonald's) are places where meals are prepared. Both contain all of the tools and ingredients needed to prepare meals, and both provide the space necessary to prepare meals. They share a lot in common, but they are also fundamentally different.

Kitchens support the ad-hoc creation of meals. A well stocked Kitchen enables a chef to prepare almost any meal. The only limits are the skills of the chef and the available ingredients. The quality of the meal is very dependent on the skill of the chef.

Fast Food Factories support the structured creation of meals. Each Fast Food Factory is optimized to produce specific meals, quickly, and in great quantities. The quality of the meal prepared in a Fast Food Factory has little to do with the skill of the operators. Meal quality is controlled by the quality of the ingredients and the process by which they are assembled.

I haven't done any surveys, but I suspect that people who really like to cook would rather do so in a Kitchen than in a Fast Food Factory.

Software comes in all sizes, shapes and flavors (so to speak)... Some software is "Kitchen-ish" and some is "Fast Food Factory-ish". Think Microsoft Office vs. Turbo Tax. Ad-Hoc creation vs. guidance through a Structured Process.

When gathering requirements from potential users, be very wary of the "dream kitchen scenario". People will often describe "dream kitchens" rather than the "fast food factory" that their business really needs. They will describe software with powerful features that can be used in any combination. They will describe software that is flexible enough to be used for all of the scenarios that they have experienced. Metaphorically speaking, they will describe the kind of stove, refrigerator and sink that they want, and they'll probably be very explicit about what these appliances should look like (brushed stainless steel, of course). Lost in all of these details may be the fact that they only cook burgers, and if they don't cook burgers faster than the competition they will go out of business.

I'd suggest that, regardless of requirements, most of us can get a good idea of what role the software will play in the business. If the software is destined to play a major role in an important business process (as most software is), then architect your software (as much as possible) to function as components within a larger process (that is likely to change). Back to the Fast Food Factory... there are many specialized components, but the interfaces are designed for movement. Each component accepts output from a previous component, and passes results on to a later component. Components themselves may be black boxes, but the connections between the components are highly visible. Traffic between components can be monitored, and if necessary rerouted should a change in process be necessary.

Why are we going?

Fabrizio is worried about where Java 7 is going and about the topics that the community perceives as the most important.

I share many of his concerns about where the language is going, but I am also wondering why the Java language is changing at all?

Are problems with Java itself prompting change?

Are external factors prompting changes to Java?

Is Java changing just to change?

I sincerly hope that the last possibility is not a big factor.

This work is licensed under a Creative Commons License.