Dealing with God Objects

(This post originally appeared at: https://www.linkedin.com/pulse/dealing-god-objects-duncan-k-g-campbell/)

At some point in the life of a programmer one will work on a legacy code base with an all-powerful, all-pervasive god object.

God objects provide a superficial simplicity that is all too attractive to both the novice and the stressed programmer. Placing all one’s faith in the god object feels like the right thing - it certainly feels easy, at first. The innocent programmer begins to fashion the god object, imbuing it with knowledge that no other object dares to possess. The god object becomes the answer to the programmer's prayers:

• Where is the control logic? The god object.
• Where shall I put this new logic? The god object.
• Where shall I find the state of the system? The god object.
• Where shall I seek out the answers to my questions? The god object.

But soon enough its complexities become unfathomable.

The god object’s mysteries need to be fully understood before one can make an alteration or an addition to the functionality of their realm.

Once the god object is all powerful the novice who does not understand its mysteries risks falling victim to its wrath as calamitous consequences are unleashed. Hours, days and weeks of debugging follow the tragedy as valiant efforts are made to clear up the mess. The new novice has now learnt that only the truly enlightened dare to approach the god object.

Documentation

The mysteries of the god object are great, and those mysteries are recorded in the great documents.
The elders tell you that only through deliberate study of the documentation may you come to understand the mysteries of the god object.

From the outside the documentation may appear to be a single document, but it is actually a collection of documents from various authors.

Some documents tell the story of the god object, of how it enabled the creation of the system. Others tell of how one has interacted with the god object.

The documents were written long ago, but often after the events they described. A few dedicated individuals attempted to keep the documents up to date, revising them, but in the course of doing that they introduced inconsistencies and even some contradictory passages, leaving the documents not wholly truthful.

In the past there were many more documents, but one day the management convened a meeting of the senior programmers where they argued about which documents should be included and which excluded from the definitive set of documentation. Eventually they agreed, and non-canon documents were removed and archived.

The novice programmer may find that the documents have little bearing on the current situation one finds oneself in. They were written a long time ago and the authors of the documents are long departed. This leaves one with different interpretations of those documents; in intrepid programmer may even seek out the previous versions of the documents in order to better understand the intent of their authors.

Child God Object

A time may come to pass when a child of the god object is seen to hold similar power as the god object itself.

This may lead to some confusion. Is the child of the god object a separate god object? Are the god object and the child god object really one god object that is both separate and indivisible?
Beware of creating new god objects.

Priest Class

The need to understand the complete mysteries of the god object act as a hindrance to change. Rapid progress in the system is thwarted by the need to fully plan for and test the consequences of each change throughout the whole of the system.

Instead of communicating with the god object directly an intermediary shields one from full exposure to the mysteries. Separating the concerns of the god object from those of the new functionality, the priest class allows one to communicate through priest objects acting as intermediaries. The new isolated functionality can be unit tested with the effects of the god object mocked. The calls from the priest class to the god object can be analysed and meditated upon in isolation from the new functionality.

One comes to trust the priest class, but one is never quite sure whether it understands everything the god object does. But as the priest classes become more prevalent it is important that different priest objects serve different parishes with their own particular congregations of objects and functionality, otherwise the priest class risks becoming as mysterious and all-powerful as the god object itself.

The priest classes may start off using the same language as the new features, but as new features are added they use new languages while the priest classes continue to use their own older language.

Eventually the priest class can remove all direct interaction with the god object, and one day some Zarathustra will say that the god class is dead.

Mob Programming: not as crazy as it sounds

Thanks to Agile Singapore I saw Woody Zuill speak about mob programming yesterday.

I'd been sceptical about mob programming at first, probably because I'd only heard the term and a one-line description of it rather than hearing from the main proponent of it himself.

The "mob" is not quite the whole team, the "mob" is all the right people being in the right place, at the right time, and working on the same problem on the same computer.  As it happens, that is also what a whole team should be: all the right people.  So, you do not need extra programmers, but you do need the people who know the requirements, understand the system, know how to test it, and sufficient to program it.

What's perhaps more interesting is that mob programming just evolved naturally out of the environment that Woody had cultivated - it was the right thing that needed to be done at that time and it was the right team.

What seeds had been planted to cultivate this environment?

For a start the team was used to working together on problems.  There were weekly study sessions, weekly coding dojo practice sessions.

The team was focused on getting better by effectively using retrospectives so that they could produce better results.

The team - the team of professionals - was also trusted to be able to decide for itself how best to work on something.

Mob programming then began when the team got together to re-familiarise itself with a project and its horrible code base.  Then they just started working on it together.  Then they just carried on, working together on one problem at a time.

Like pair programming, mob programming has a driver-navigator relationship, but in mob programming there is one driver and many navigators.  The programmer as the driver in a pair (or mob) is a "smart input device".  (This is unlike my first experience of pair programming when everything wrong was done, resulting in me acting as a typist for my partner without any thinking going on in my head.)


Mob programming also makes various problems just disappear.

Communication is not a problem when you have all the right people together in the same place at the same time.  The same goes for decision making and meetings.  Thrashing is also eliminated as one problem is completed at a time.

Having the whole team with the same attitude to quality acts as a barrier to the introduction of technical debt, so too does having the whole team understanding the system and working on one problem at the same time rather than producing dissimilar solutions to similar problems.

So mob programming is not as crazy as it sounds, but for it to work you need to have cultivated the right environment, which is not a bad thing to do anyway.

Normalisation of Deviance

Piers Bizony's article "Challenging the Establishment" in the 6th September edition of Engineering and Technology introduced me to the phrase "normalisation of deviance"

Essentially, when there is normalisation of deviance people accept the current practice (regard it as normal) despite it deviating from best practice, or they may not realise what best practice is.

If anyone then comes along to change anything, the practitioners of the normalised deviance question the need for change.

"We've been doing this for so long and nothing has broken, so why change?"

Then something catastrophic happens such as the Challenger shuttle exploding because of frozen rubber O-rings causing a leak in the solid fuel booster rockets.

Normalisation of deviance also applies to poor software engineering.

"I've never had to refactor code/write shorter methods/use descriptive names/etc before, so why should I start now?"

"This code was written before and accepted, so why should I change it now?"

It become acceptable that code is hard to maintain because "that's just the way it is".

In software engineering this deviance will manifest itself in high rates of bugs and increased development costs as software maintenance becomes increasingly costly - not as dramatic as a space shuttle exploding.