Striving Towards Liveable Code

A few of us in the Palatinate Tech team took a trip to Brighton recently to attend the Brighton Ruby Conference. For many of us it was our first conference, so we were all giddy with excitement at having a day by the seaside meeting interesting people and learning more about our beloved Ruby.

Without a doubt the most interesting talk was Sarah Mei’s exploration on the concept of “Liveable Code”. A decent talk should make you think. It shouldn’t be so obscure that it sends the demons of imposter syndrome to visit you in your sleep, and not too obvious and simple to lead you to think you’re wasting your time.

Liveable Code was really a giant metaphor for how a team should work together to produce a codebase that works for everyone. We like to think that a perfectly abstracted codebase with no duplication and cleanly separated concerns would solve a lot of our problems. We dream of the rewrite, where stakeholders within the business get on board with the idea that if we just spent 5–6 months rewriting our old (Insert your most hated language here) app in (insert your favourite new shiny hipster language here), then we’ll be delivering so many features that they’ll become bored of us delivering features!

Much like developers dreaming of that ever elusive “perfect codebase”, we have homeowners dreaming of the perfect home. A clutter-less, immaculate space with no mess and every item stored in its rightful place. We look at a staged home in brochures and interior design magazines and think “Wow! This home is perfect”. But the reality is, as usual, not as simple. A home like this would be quite frustrating to live in. Some people usually want the TV remote on the sofa, not hidden away in some RemoteStorageContainer where it must be placed back at all times. Some people may want books spread around the house, on living room tables, or in the kitchen and even in the toilet! Not just stored in a BookRepository that can only be accessed in one place.

We as developers constantly read books on “How to Write Maintainable, Flexible, Beautiful Software”. These materials usually provide examples of highly abstract codebases with little coupling between application layers and responsibilities between components heavily limited. We then go back to our jobs and weep uncontrollably, distraught at the fact that we’re stuck with a technological rat’s nest of outdated software that’s riddled with bugs. Much like the homeowners reading through interior design magazines, we’re fraught with envy.

Mei sees a codebase in two states; one where it’s so messy that it’s becoming harder and harder to reason about. The other state is the opposite, where the code is super abstract and it’s hard to figure out what happens when the user actually interacts with the application. A staged house like the the latter is similar to our perfectly abstract codebase. It’s clean, looks great in the pictures and we envy the people who live there. But once we’re inside and living in this room, we realise the chairs aren’t so comfortable. There’s no bin to discard of our chewing gum. The cushions on the sofa, whilst nice for decoration, become an inconvenience when all we want to do is lie down.

A certain amount of clutter in a home is necessary depending on who the occupants are. A parent with 2 young children isn’t going to want the staged house in the picture. They’ll want a few toys lying around to entertain the kids. They’ll need easy access to pots and pans in the kitchen in order to prepare food. Much like a home, the structure and pattern of a codebase should evolve with the needs of the team.

When a group of flatmates take in somebody new, they don’t want to have to explain every tiny detail with regards to where things are placed. They want their kitchen to be like most kitchens. An entire drawer for cutlery, instead of a drawer for each type of cutlery to help separate out our kitchen items in the name of “clean storage and future drawer extensibility”. Much like when we onboard new team members, we want them to get up to speed as quickly as possible. Having an obscure pattern that makes the application flow very opaque doesn’t help with this process.

Whilst this talk was good, I feel there were some issues that were not addressed. Sure living in a staged home with no clutter would be undesirable for the reasons described. We don’t mind a bit of mess, so long as it’s our mess. Leaving the remote control lying around or books slightly out of place would infuriate the most fastidious of homeowners, but leaving a bit of mess in a house to make it more comfortable is not the same as leaving a slight mess in a production codebase that a business heavily relies on for its revenue streams.

Leaving the dishes unwashed for a day may give you some relaxation time, but it’s still a form of “debt” that you have to pay in the future in exchange for an easy time right now. Leaving a critical piece of production code untested, or a piece of functionality coupled to another part of the application could cause bugs that lead to an actual erosion in profit margins.

While Mei’s metaphor is both cute and thought provoking I feel that it might give some developers an excuse not to strive for perfection. We’ll never produce completely bug free software, much like neither of us will ever become the perfect developers we want to be. But striving for that goal is still something to aim for even if it’s not completely within reach. The main takeaway from Mei’s talk is that we should shy away from the extremes, both uncontrollably messy and perfectly abstract, in favour of a codebase that tolerates some mess in exchange for an easier developer experience. I would be afraid if this gave developers an excuse to write sloppy code with the reasoning “But it’s our mess”.

Palatinate Tech is currently hiring and as luck would have it is opening offices in Brighton this September. If you want to join our team then get in touch!