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.