Hacker News Reader

Comment by codingdave | Hacker News Reader

> it is advantageous to minimize how often ownership changes hands - no one will ever know more about a thing than the person who created it.

This may be true when looking at a single individual, but this is exactly how teams get locked into the bus factor of 1. The person who creates a codebase needs to train others on their knowledge, so the entire team has that understanding that allows them to be productive. The slowdown to train someone up to know as much as the creator is quickly paid off when 2 people know the codebase. And it scales more with each new person because not only do more people know it, but the knowledge transfer gets streamlined and the confusing parts of the app are identified and fixed.

View on HN

I've begun to feel like we might put too much value in the "bus factor". Many companies have de-emphasized specialization in order to "spread knowledge and context". I think that's resulted in worse job satisfaction and developers who are spread too thin.

Not to say every person should have a silo-ed portion of the codebase that nobody else ever touches or understands. I just think the pendulum has swung too far in the other direction.

Not to say every person should have a silo-ed portion of the codebase that nobody else ever touches or understands. I just think the pendulum has swung too far in the other direction.

Yes. It's one of those mythical management "best practices" that never actually happens because it doesn't work.

Most interesting software development involves creative thinking. Unless someone finds a way to download the entire thought process of the original developers and losslessly transfer it to other developers later you can't recreate 100% of the knowledge and insights that came from the original development work.

What you can do is acknowledge that your developers are individuals with unique knowledge and abilities not just in general but because of their history within your own organisation. Value the unique experience they collect while working with you and - for as long as they remain with the organisation - encourage them to actively support colleagues who are later working in the same part of the code.

There is no substitute for retaining that knowledge and having the original source directly accessible but of course most people do move on eventually. So it's also a good idea to emphasise good design and coding and documentation practices so that even when the original developers move on and you'll never have access to the ideal source of knowledge again you still have enough to figure things out when you need to. The fallacy is the idea that working that way will ever be comparable in productivity to having the original source still around and willing to help.

So well put. I think one of the sources of burnout for many developers is the complete lack of acknowledgement of the creative aspect of programming in modern development processes.

I’m curious what others have experience here, as a code base grows.

I’ve been on several teams that consistently endeavor to keep the knowledge of a code base shared, but every time the code base reaches a certain size, the Bus Factor creeps right back in, but this time for “modules” or areas of the broader code base.

Combine a large code base, 4-8 engineers making constant changes all over, and it becomes a real struggle to keep everyone “up” on the whole thing.

Has anyone seen a workable strategy for this?

Making sure someone has enough knowledge to cover an area: giving a man a fish.

Encouraging the mindset to be able/willing to learn new areas as needed: teaching a man to fish.

Reply on news.ycombinator.com