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

pinSeeing the Wood for the Trees

Overload Journal #126 - April 2015 + Programming Topics   Author: Teedy Deigh
The outdoors is fabled to be great. Teedy Deigh suggests your code reflects your environment without ever having to look out of the window.

It’s good to go outside and enjoy nature every now and then. Apparently.

For screen-hardened programmers this can present something of a challenge. Outside is a domain normally negotiated in order to get to and from the office, or for stealthy forays to the nearest supermarket to stock up on drinks and snacks to fuel a night of hacking on some open source or simply correcting someone in an online forum. If you want to actually admire it, well, that’s what pictures on the web are for.

But it’s possible to have your cake and eat it without even going to the supermarket! Look at your code. What do you see? The chances are, if you work in a proper enterprisey system, your code will reflect your environment: managers, proxies and singletons everywhere, with work avoidance, vague responsibilities and unclear methods characterising how tasks are partitioned, resources are allocated and goals are met.

Lots of bureaucracy and not a lot of action – and that’s just the identifiers.

Names and titles matter, as any interim managing senior principal vice president of idempotent operations will tell you, but what we usually see in enterprice code is dominated by MBA thinking and tired industrial metaphors. It’s not just the manager and controller and factory and service objects, but also the need, for instance, to clarify to readers that an object that is thrown as an exception and caught as an exception is an exception by including Exception in its name, or that a class defined as abstract needs to be named Abstract just in case the memo didn’t get through. Droolproof paper is in increasingly short supply.

We see the division of labour in conventions that stretch from naming into the architecture. The traditional class struggle – where there are those who talk about the work and those who actually do it – runs through codebases like a naked Marxist through an overdressed stock exchange. It is not enough for objects to be manufactured, managed and stripped of behavioural responsibilities so they deliver little more than data: they must also conform to interfaces and contracts. Depending on convention, there is the me-centred I prefix, which is popular with millennial programmers, or there is the contrapuntal summoning of supernatural creatures that hold the promise of behaviour, the Impl suffix – a contraction of ImpWill.

The problem with these homeopathic naming conventions, where affixes are continually added to a name to dilute its meaning, is not simply that they reduce the informational content of information technology: they project, coerce and reinforce an industrial and post-industrial view of the world onto the semiotic space of our noosphere.

But it doesn’t have to be like this.

Where is nature? Where are the rural styles of coding? Instead of software architecture, what of software agrarianism? It is possible to reclaim a more rustic and ecologically balanced approach to code, whilst still ensuring sufficient verbosity to win the enterprize. And all this can be done without setting foot outdoors!

Consider logging. This practice is rife in both tropical rainforests and enterpricey systems. It is generally arbitrary and unsustainable and few people are ever clear what the exact requirements are, so it spreads like a cat meme. It would be simple enough to pass a log in only when it is needed, or to define a need during construction rather than introducing a global trade dependency, but it is clear that to be taken seriously by the enterprison we must work closely with the existing architecture and start by rebranding.

For familiarity’s sake we can keep the Log class, but where do logs come from? The conventional answer is a LogFactory. But no, work the metaphor: a Forest! And how should they be managed? By a LogManager – or by a Lumberjack? These should be defined in a timber package, with a specialisation for SustainableForest –which throws an IllegalLogging exception when overused – and a specialisation for PoorlyManagedForest – which is deprecated with immediate effect. Rather than write to a log, we can carve, and rather than dispose of a log, we can fell it.

Such subtle shifts in style allow the preservation of an enterpies growth model, but give developers the illusion of doing something worthwhile, offering them a simulated engagement with nature, but without all the nastiness of having to actually go outdoors.

Overload Journal #126 - April 2015 + Programming Topics