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
|Browse in :||
All > Topics > Programming (768)
Any of these categories - All of these categories