A previous project I worked on was to create an abstraction around various command-line invocations, the context here was automated testing on different platforms.
The idea is pretty simple, rather than having to keep track of command-line flags and options, you just call this CLI and get a nice JSON formatted response.
I knocked out a handful of commands, as did several other developers, and that’s where things got interesting. Despite being both a young project and a simple one, discrepancies had already crept in.
The code was not bad, and generally worked at what it had to do, but reading through different sections it was apparent that different conventions had been used in different places.
How did this happen? Code was reviewed, and I like to think we were all competent developers, but that’s not enough.
The real problem was that this code had no “owner”. There was no one to say “we’re doing it this way, with this convention”.
In The Mythical Man Month the author presents the metaphor of a surgical team. The surgeon is ultimately the one calling the shots, and likewise, a team of developers needs a singular entity whose mind is reflected in the codebase.
I don’t think this is prevalent in the industry, though the open-source concept of a “benevolent dictator for life” often fills this role. An entity who informs the overall architecture as well as the more minutia conventions followed on the codebase.
When looking over a piece of code, we might do well to ask ourselves “who owns this?” If the answer is “no one” (or the more inclusive but equally unhelpful “everyone”) perhaps we should ask why that is. If you’ve ever looked at a codebase and found different sections use different styles, conventions, or naming schemes, you’ve probably seen what I’m talking about (not 100% certain, it’s possible the team has jointly experimented on different approaches over time, though in my experience this is seldom the cause).
Terms like “Tech Lead” and “Senior Developer” can mean many different things in different organisations. Nevertheless, to me, one of the signs of the “leadership” or “seniority” of a developer is their ability, even their desire, to care for the product and codebase on a wholistic level. As a junior my main concern about code was “does this work?”, but as I went on in my career this expanded to include questions like “does this match the existing codebase conventions?” and “is this architected so that it can be extended later if needed?”. I think this is a natural progression in a developer’s career.
One of the main hindrances I’ve encountered against code ownership is at an organisational level. If no one is nominated as “lead” or “senior”, then everyone is on equal footing. This can make it difficult for developers to “push back” during code review, as everyone (theoretically) has equal weight in the discussion and so no one has the final say. It can also lead to environments where, somewhat deliberately, no one wants to take the lead - everyone just works through their tickets in their little section of the codebase, using whatever style or conventions they prefer.
So what’s the solution? Someone has to take ownership of the codebase to ensure consistency. This doesn’t mean they have to change what’s already in place, nor that they have to enforce their particular preferences onto the whole team. Anyone in this position should be someone who knows the difference between “I wouldn’t do it this way, but it’s ok” and “in this project, we follow the convention that X”. The ultimate goal is to make the codebase, as a whole, cohesive - not to make it look like it was written by a single developer.