Another reason for TDD

It seems that one can never have enough good reasons for espousing Test Driven Development (TDD). If there is a dearth of cogency in this argument, then I hope the following helps.

One way to think about a robust test suite is that it is something akin to a safety net against creating unsafe software. The definition I have in mind is coincident with what Donald Norman calls a "forcing function", and is sometimes referred to as Poka-yoke.

Consider a kitchen appliance such as the food processor. To run the food processor, you must assemble the various parts in a precise way. Consider just the lid for the moment. Not only must you lock the lid in place; it must also unlock the hidden safety switch with the projecting cam (see figure).

If the cam is broken, then the food processor will not run, even if the lid fits snugly on the bowl. While it can be distressing if the cam breaks during washing the lid in the dishwasher; the cam provides a forcing function, preventing unsafe operation of the food processor.

TDD can be looked as a practice of providing a comprehensive forcing function for software. If the tests are broken, the software will not run (would not build in most cases). It can be vexing when the build breaks because of failing tests, but the tests prevent producing unsafe software.

So the next time someone complains about tests failing builds, politely ask them if they'd like to use a blender that ran with or without the lid.

Upgrades and Shovegrades

Quite often, you feel that you really don't need the new version of a certain piece of software; but you really don't have a choice. You simply cannot keep working with the old version -- the decision is not yours to make.

This is not a Luddite argument. Technological progress is eventually inevitable -- even change (as opposed to progress) is a fact of life. However, when bad change is thrust upon unwilling and unsuspecting users, it is at least proper to call it by its correct name: a shovegrade.

Perhaps the neo-classical example of a shovegrade outside the software world is the so-called New Coke. What made it feel like a shovegrade was not just that it was a "change", nor only that it was "unsolicited"; nor that it was "compulsory"; nor that it was "less appealing" -- but that it was all of those at once.

This gives us a fair working definition of a shovegrade: An unsolicited compulsory change which results in a product that is less appealing than before.

In software , many upgrades are in fact shovegrades. The reason this is prevalent in the software world is because it is relatively easy to retire one version and move to the next. License keys (especially those managed through a central license server), time-bombs, deactivation of online support accounts, version management through Push Technology -- all these make it possible to forcibly shove new versions of software instantly down
the collective throats of all consumers.

I experienced recently an example of a shovegrade on a large project. The architecture team (to which I did not belong) created a new API to handle the concept of Time and shoved it down the throats of all other teams (including the one to which I did belong). The real implementation problems this new Time API caused were unanticipated by the architecture team. Since the old implementation of Time had been removed (not deprecated), and the new API failed to deliver key "-ilities" (reliability, simplicity and others); this felt like -- and was, by my definition above -- a shovegrade.

The underlying fact -- that the architecture team failed to anticipate the problems caused by the new API -- was due to their lack of involvement in the design and implementation of the domain solution. In one sense, this is a lack of application of the Architect Also Implements organizational pattern.

That is a topic best handled elsewhere.

Frontispiece

This blog lists my musings on software.