Consistent Codebases

One of the Things I've often heard we should aim for as software engineers is a high level of consistency within our codebases; a respected colleague once argued that it is the highest priority we should have, beyond even "good" code. Reflecting on an old project lately I've started to wonder a little. I don't really have an agenda here, this is likely to be a rambling stream of thoughts without a firm conclusion.

It seems like consistency goes hand-in-hand with clean code (is possibly a part of it - I never did finish that book); much as good naming tells you what things are or do, consistency in a mid-large codebase shows you how to do things; reduces the time you should spend thinking about this so you can concentrate on the implementing (one of the promises of Golang). But what if a codebase is consistently awful? Or consistently written in a way you really don't like (hello again Golang)?

My former colleague would probably still argue that that's a good thing, and I'm not going to say he's wrong. Not completely, anyway. What I can say is that I did for a while have ownership of a tremendously consistent codebase once and I think I can honestly say most of my team strongly disliked working in it. Working on that app was drawing the short straw.

I'm not going to finger wag; the team who built it had a lead developer with Very Strong Opinions at every level and it's kind of admirable how he got them to follow his vision. It had remarkable test coverage, used some pretty cutting edge ideas and a decent tech stack and it was all put together in a very particular and consistent manner. But we still hated it.

Primarily there was a very distinctive pattern applied universally which you really had to follow and which made adding the least feature a tedious exercise, especially where external dependencies were involved. There was also a frustrating coding style which seemed to work against the language being used.

In contrast the main app we were responsible for was a glorious mess of a monolith, and it wasn't even old. Somehow this greenfield had bloomed into a monstrous tangle of who knows how many varieties of plant from thorny, hard-to-remove weeds to delicate wildflowers. A garden more of English Romanticism than French Baroque formality. Or maybe the kitchen garden of a largely abandoned monastery, every patch tended by a since departed and highly idiosyncratic monk, now growing into one another and encroached upon by surrounding wildlife.

Anyway, lots of people hated that, too. But it was a much more interesting place to go for a walk.

When I got my first "proper job" it was at BBC Television Centre in Shepherd's Bush. Now this complex was (sadly and wrongly, it was sold for redevelopment) a wonderful, terrible agglomeration; a patchwork of buildings off-centred on the ring known fondly as "The Doughnut" (one of the few things that has happened to me in my life that I could describe as a "rite of passage" was doing a circuit-and-a-half of The Doughnut on my second day there having failed to recognise the office I was looking for). I was somewhat bitter when the team I was working on got shunted down the road to the bland - and, yes, let's say it: more consistent - White City building. That said, White City was nothing compared to the Broadcast / Media Centres - they took consistency to a whole new level with identically laid out floors navigated according to Star Wars Droid designations (BC3B1, MC4A2...). You could easily get lost there too, but not in a fun way.

Where was I? Oh yes, fun is important! I genuinely believe that enjoying work can boost productivity both individually and for a team and perhaps some of the things which make work fun are either taken for granted or even dismissed without thought, especially when they're environmental - and the codebase is an environment. Is it nicer to go for an urban walk in the centuries-long layering of collegiate warrens that comprise Cambridge or the new town rigidity of Milton Keynes? Do you want to get your bearings by looking up to see which particular bean factory you are currently working in (to those unfamiliar with software development "bean factory" may sound like a metaphor. Sadly for many it is not) or, metaphorically, to kneel down and check the animal droppings and compare against your experience of the local fauna?

I may have taken this too far.

I wouldn't say people should deliberately engineer inconsistent codebases (maybe I should?), though if you are building an app with a microservice architecture, engineering each app with a different language or framework as some recommend may to some extent have this effect. One of the main arguments against that is that context-switching is expensive, and I strongly suspect Consistency Advocates (our enemy has a name at last) are the kind of people who bang on about that. Perhaps context switching like this might actually help with orientation, knowing where you are working and therefore what kind of problem you are solving. I've heard this said about the difference in style between test and production code, at least.

Could diversity within a codebase, rather than being a bug-magnet, in fact introduce some element of immunity against certain classes of bug? An unsuspected flaw in a consistently applied pattern is now a flaw which is throughout the entire system, after all. shrug I don't know.

I think my ramble is coming to an end, and like my favourite rambles it is somewhat aimless and I'm not completely sure where I've ended up. Perhaps the best takeaway from this is that maybe consistency is not the be-all-and-end-all and that if you do find yourself working in a sprawling mess of a codebase then before thunderously denouncing it, see if you can appreciate its merits - stop and smell the roses while being careful of their thorns. And of course, it takes all sorts - there is no One True Way, so if consistency floats your [-team's] boat then that's where you're better off, too, and to be honest I think I'd rather life-preserving software was rigorously and consistently engineered than left to go to seed according to the whims of some eccentric engineer because they thought it would be fun.