I am pleased to report that the campaign goes well thus far.

We met the enemy at the border of Weblogic, and battle was joined, SVN commits clashing with intractable lengths of binary spaghetti at every turn.

Our original plan was to crush all remote beans entirely, liberating the entire application from this particular scourge. Much progress has been made towards this goal, although the enemy is powerful and resourceful.

We can confirm that at least five of our opponents fell early in the glorious battle, with minimal losses on our side, despite the heavy resistance. At several points in the battle the WTF/minute meter was rising to dangerous levels. One particularly brave refactor was rolled back in a blaze of glory, still muttering “stay in target directory… stay in target directory”…

Our initial attempt at penetration of the enemy’s lines was at the JMX pass. Despite valiant attempts by our brave tests, we were eventually defeated in this attack by proprietary “extensions” to what should have been well-accepted standards. The enemy knows no shame, and will stoop to perverting even innocent RMI for it’s nefarious purposes. In fact, they dredged up what should have been long-forgotten and discarded protocols to throw us off the track, even resorting to JMX over IIOP, with proprietary client libraries, which was too much for us – we could not withstand that level of firepower. We had to find another way.

We were repelled by the evil machinations of the enemy’s classpath conflicts at the battle of the EAR, but were able to outflank them and retreat to a previous revision number with minimal losses. We then regouped and attacked again in the region of the remote stateless session bean, and only one of the enemy escaped our wrath. We will be watching this one remaining combatant carefully, and at his first slipup he is sure to be doomed as well. We have assigned our best integration test to watch his every move.

Despite attempts to deceive our troops with obscure and fiendish JNDI naming practices, we were able to ensnare many of the enemy in our powerful web of functional tests, where they can do no further harm.

At least four entire modules of the enemy’s forces did not survive the encounter!

We have won this conflict for now, yet many challenges still lie ahead in future battles. The enemy used many clever tactics this time, but we have not yet encountered their ultimate weapon: the greatly-feared container-managed entity bean! Weapons of mass deprecation of this nature must not be allowed to continue to intimidate future generations. Massive as these weapons are, they are slow and no match for our lightweight DDD techniques – we will lure them into shallow memory and watch them go aground, tangled in their own distributed transactions.

For now, though, our troops have withdrawn to the safety of our own home OSGi modules, where order, structure and modularity reign supreme.

Stay tuned for future reports….

Often, in the software development game, we’re asked to add a feature to an existing system. Sometimes this system has been around for a long while, as there’s no notion of “planned obsolescence” in much of software.

I recently encountered a situation that is highly symbolic of the problem, if not an actual software issue, per se.

At an office I’ve worked in, they have very nice washrooms (yes, this is related to software – bear with me here). They’re modern, with nice clean stalls and such, and feature toilets with the “auto-flush” feature you’ve no doubt seen elsewhere.

Once you’ve finished your transaction, you just finish up and leave, and the sensor detects you leaving and auto-flushes the, ah, buffer, for you. Excellent, now you can be free of having to remember to do that yourself, and assured that it’s already been done when you enter the stall. Kind of like auto-commit on a JDBC connection. Well, kind of.

Anyway, let’s talk about feature conflict.

A new feature was recently added to this fine setup: paper seat liners. You’ve probably also seen these – they’re the nice little rings of paper in a dispenser, usually on a wall, that allow you to isolate your back-end interface from the implementation details of the toilet seat.

Also very fine idea. In the case of this particular washroom the dispenser for these is attached to the wall behind and above the toilet itself.

Taken independently, each of these features (auto flush and seat liner) seem like perfectly good features, and their implementations are quite reasonable. In functional testing, each performs exactly as it should.

The difficulty comes in integration testing, when you try to use the system as a whole.

Let’s take a use-case and walk through the scenario: The – ah – user enters the system. Standing in front of the toilet, he (definitely he in this particular case) decides to avail himself of the seat liner, and removes an instance from the dispenser. No problem. At this stage, the auto-flush sensor has already detected the presence in it’s scope, and does nothing, as it doesn’t trigger until you leave the area.

Now an implementation detail: the way the paper liner works is that the spot in the middle of the paper is cut out, and drops down to touch the water, while remaining attached to the remainder of the liner. The idea here is that when the water leaves during the flush, the liner will be drawn down into the bowl with it, and appropriately de-allocated. As we’ve said, previous functional tests verify this works just fine.

Now let’s assume the user has correctly deployed the liner, and wishes to transact his business. Well, if you were facing the toilet when you came in, you probably don’t want to be anymore at this point, so you turn around. Here’s where the feature conflict rears it’s ugly head: the flush sensor, noting the movement, often picks this moment to decide it’s time to flush.

The liner, having deployed correctly, departs the scene at this point, just as the user completes their interface. Unfortunately, that is the moment at which the liner is supposed to be there. You see (or, more correctly in the case of the user, feel) the problem.

So, which feature is broken? Taken one at a time, neither is broken – they both do exactly what they’re supposed to do. The failure is at the point of the wholistic view of the overall system, and neatly demonstrates the fact that it’s impossible to consider features or potential features in isolation, in any system. You must consider scenarios of users actual interactions with the system, and how the new feature will affect those scenarios.

Nobody said it’s easy, but it’s important.

I was recounting to a colleague the other day a story that is probably much funnier to fellow developers than anyone else, and thought I’d share it here as well.

I had the opportunity for a number of years to work with a software team in the Bahamas, for a company with operations there. They were a great group to work with, and we did some good stuff. The Bahamas has it’s own “dialect” of English sometimes, however, and it was a while before I got used to the slight differences and accents from my native Bermudian.

One of my favorite elements of the unique Bahamian dialect is their use of a unbound variable in natural language.

You know when you’re talking about something, and the name of a specific piece of technology escapes you? Well, those of you with younger memories maybe don’t have this mental lazy-loading happen quite as often as us old geezers, but I’m sure it happens once in a while. You’re saying something about a webapp deployed to a cluster and you want to refer to the device that distributes the processing load of the users across the machines in the cluster. “Load balancer” is the term you’re looking for, but your brain has hit a bad sector and is busy doing an fsck, so you stammer over the right term.

Bahamians have invented a term especially for this situation, and I call it the “unbound variable” in natural language. We’re not sure what it’s value should be in this situation, but it serves as a place holder when we think of the right word later on.

It’s called “tingum”, pronounced just like you’d expect, with a short “i”. Its considered bad form to pronounce it “thing-um”, I understand, even thought that might be the root of the word originally.

So you can simply say, “When the tingum moves a session from one server to another”, rather than having to actually work out the necessary technobabble to go in that spot.

It saves us the trouble of having to come up with new terms at random, like “whatsit”, or the much more verbose “thing-a-me-bob” or “whatchamacallit”.

It’s important not to bind this variable to any one term, even if it later becomes clear what that term should be in any one context, because that would reduce it’s generality. If you know that tingum should be bound to “load balancer”, you might inadvertently use it in it’s bound form in the wrong sentence.

In this sense, it’s rather like “_” (the underscore) in Scala – it’s *supposed* to be unbound.

So, the next time your mental RAM gets a checksum error and you can’t remember the correct technical term, keep the “tingum” in mind!