Afterwood
It’s interesting to watch other professions at work. Unless you work on the ground floor of a glass building or sit on a train with a monster-sized laptop it’s highly unlikely that Joe Public is ever going to be able to watch you writing software without being highly intrusive. Even if someone is visiting the office much of what happens is on a screen that is too small and inappropriately angled to see what’s really going on; an impromptu huddle or conversation around a whiteboard is about the only glimpse they might get of us in action.
Sitting in the queue at the hairdressers – a traditionally open-plan workspace – you can watch the staff at work. While plenty of time is spent working directly with each client to make their hair look special there are other activities which take place before, during and after which are not directly related to styling the client’s hair, but nevertheless still contribute to the experience for both the client and stylist. For example it’s quite common for a member of staff to be wandering around with a broom constantly sweeping the floor. This task is not solely performed by some intern or graduate who’s beginning to learn the ropes but may be done by senior staff too if the need arises rather than let the pile of discarded hair accumulate. Similarly their core tools and products are readily accessible, you rarely see a hairdresser wandering around trying to find a pair of scissors or some styling wax.
I find the same can be true of building sites, whether it be large scale construction or a new extension to the house. Decent builders will constantly sweep up and clean around themselves whilst they are working, not just at the end of the day before knocking off. Likewise people working in a kitchen can be seen wiping the sides, returning products to the store and washing up crockery and utensils.
While there is undoubtedly an element of “health & safety” in all these professions that acts as a strong driver to try and keep the workspace clean and tidy, that can’t be the only reason. The open plan nature of many hairdressing salons no doubt acts as another driver for them to keep the place presentable as the window is literally a shop window showing passers-by what’s on offer. Open kitchens are “a thing” too so that customers can sit and watch the chefs at work and be part of the entire cooking experience.
I find it hard to believe anybody truly enjoys working in a pig sty, except maybe some pig farmers, and yet those of us who work in offices (of the virtual kind where our “files” and “folders” exist merely as electrical phenomena and our “desktop” is just a visual metaphor) often seem oblivious to the virtual detritus surrounding us. Unless you’re working in an industry where lives are at stake there is no risk to anyone’s health from leaving around commented out code, ignored tests, unused source files, stale 3rd party packages, old build configurations, redundant source repositories, out of date documentation, uncommitted deployment hacks, build warnings, temporary log messages, etc.
While there are essentially no health risks, undue stress notwithstanding, there is surely an effect on productivity as people keep discovering the same remnants of days gone past and then wasting time on questioning what they’re failing to comprehend until somebody fills in the blanks. It takes time before the muscle memory kicks in so that the same discovery again and again can quickly be discarded. Even if we deal with the problem the first time we encounter it we are unlikely to have all the same context the original “perpetrator” had and therefore it will take us longer to correct than simply doing it properly first time around.
While commented out code is trivial to deal with, dead code is often much harder to isolate even with modern refactoring tools unless it literally has no call sites and is not an obvious target for invocation by reflection either. Writing unit tests is great for live code but it hides dead code from our tools. Even when you don’t have any tests keeping it alive, finding the roots and checking if they’re still live can require a fair bit of legwork.
Ancillary code such as the tools and scripts used to stitch together build, test, deployment and support processes can often accumulate a large amount of cruft over time as their “non-production” status frequently grants them only 3rd class citizenship. Their very nature can be highly environment specific too meaning that any change is going to be tricky to test and therefore proving redundancy could be non-trivial.
Not all changes start with a clear entry path that leads to an obvious test plan either. Often we find something that needs changing and then go looking sideways to find similar points of interest, such as the same type of mistake made elsewhere or where the same code could have been copy-pasted rather than factored out. Once we find them, unless we are going to simply “hit and hope”, we have to navigate back out again to work out how we’re going to test those changes too. Choosing not to join up the dots and blindly changing redundant code or configuration only adds to the appearance of liveliness.
Remember when you were a student or first shared a house
with other people you didn’t really know? Don’t be that person who puts
empty cereal boxes back in the cupboard, leaves a useless amount of milk in the
carton and only washes up their own dishes. Please, for the sake of your flat
teammates, clean the sides and sweep the floor.
Chris Oldwood
23 January 2019
Chris is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it's enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race and can be easily distracted via gort@cix.co.uk or @chrisoldwood.