ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinRise of the Machines

Design of applications and programs + Overload Journal #101 - February 2011   Author: Kevlin Henney
Sometimes the world really is out to get you. Kevlin Henney identifies some culprits.

In the space of a few syllables, the word resistentialism is packed with humour, rhythm, profound insight, philosophy, multilingual wordplay and astute commentary on much irksome code. Formed from res (the Latin for thing), resistance and existentialism, what exactly does it mean? And what does it have to do with code?

  • Resistentialism is a jocular theory in which inanimate objects display hostile desires towards human beings.’ [Wikipedia]
  • The theory that inanimate objects demonstrate hostile behavior toward us.’ [AWordADay]
  • The belief that inanimate objects have a natural antipathy toward human beings, and therefore it is not people who control things, but things which increasingly control people.’ [WordSpy]

In a nutshell, it’s about objects. Especially the ones that seem to thwart our efforts and intentions:

  • The stateful and pervasive singleton object that increases the stealth coupling of a system.

    Complicated unit tests, reduced thread safety and tsunami rebuilds are just a few of the symptoms. Although undoubtedly introduced with the best of intentions – along with the multitude of other singletons in your application clamouring for your attention, initialisation and coordination – most singletons are short cuts and band-aids (and band-aids for short cuts, and band-aids for band-aids for...) that nurture a sense of resistentialism.

  • Uncohesive objects suffering from scope creep and over-education.

    They seem to know too much and do too much, greedily pulling in as many responsibilities and dependencies as they can. For example, value objects that also have service-like behaviour accessing an external such as the file system, a database or the network. Or classes that amass statics as well as instance-specific members, so there is an implied and missing object responsibility, such as an aggregating concept that collects or manages instances of the class. Sleepwalking into a state of resistentialism, one feature at a time.

  • Anaemic objects, strangely free of any useful behaviour: constructors that result in meaningless and yet-not-usable objects; methods that fail to encapsulate common usage or reflect the actions and queries of the domain; a type vocabulary that barely drags its knuckles above strings, integers and collections. What you get instead is a public method interface that is little more than a pass-through for the private fields – for every field a get, for every get a set. You cannot understand the system by looking at these objects – they offer little more than object-oriented assembler. Although trivial (even pointless) to test, they are incomplete and free of meaning. Their behaviour is displaced and scattered around the codebase, often holed up in large procedural or controller classes, too difficult to test or to change with any confidence or comfort. Resistentialism is the proclaimed and upheld belief system of the code and those who work on it.

Perhaps the best thing about resistentialism is that you now have a blame-free philosophical framework whose name you can call on in times of code distress. And in those times of need you also have a word you can use in polite company. Of course, in a well-crafted system, resistentialism is futile.


[AWordADay] A Word a Day


[WordSpy] Word Spy

Design of applications and programs + Overload Journal #101 - February 2011