Comment by Bahamut | Hacker News Reader

Comment by Bahamut | Hacker News Reader

I like this article on a whole, but I do have a comment on this quote

> Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

I have worked with someone overly protective of the code sector he wrote, but it has caused problems since I would like to fix some bugs in the API signature of that code, but the developer has stonewalled me in the past & raised a ruckus when I filed PRs to fix some of it. If it is something that affects how other people interface with a feature, IMO it is not a good thing to necessarily designate a primary owner & mandate all changes go through him/her. Granted, some of the problem is that the other developer probably was in the wrong being obstinate, but you work with the cards you're given.

Mozilla addresses this, in part, by having one "module owner" but also multiple "module peers". All code changes in a module should be reviewed by the owner or (more usually) a peer. Having multiple peers reduces module owners' review burden, reduces bus factor, and gives "reviewees" someone they can appeal to if their PR is rejected. Linux has a similar organization with Linus' "lieutenants".

It makes sense to have centrality of vision for how code should be laid out. This is software architecture (as skill and role, not title though!). And as people have a limited focus span, it makes sense to segment - by business topic, by API, etc. But of course fiefdoms emerge.

In some ways, it might then almost be better to not have that person contribute to same codebase: to avoid ego pissing contests and to keep the opposing pressures in balance. The pressures being: delivering features on time on one hand, and keeping things clean and orderly on the other hand. Often, if the architect codes then they can't see their own mistakes, but have 20/20 vision of others' grubby flaws, and hence gain subconscious animosity towards external contributions.

That being said, an architect who does not code is even worse! This is where we get ivory tower Architect-as-title, and even less gets done. I wonder what the optimal middle ground is.

Perhaps the middle ground is a software architect who codes, yet has high emotional intelligence and acts as a servant leader. Someone who honestly wants to help their teammates, and doesn't feel "better than them".

Perhaps they lay out a system design as a suggestion on a wiki and ask their teammates including themselves to collaborate on it until everyone's content with it.

Then perhaps they code a particular layer primarily and are humble and open to criticisms and mistakes they make in their own coding. They understand that they and others are not perfect, nor is the code they or others produce.

That and good relationships and communication with the product, design, management, qa, and support teams are what I feel would define a valuable "Software Architect".

Reply on news.ycombinator.com