Hacker News Reader

Comment by curun1r | Hacker News Reader

Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before.

As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.

View on HN

You are right that this is something to consider. In my case the "realm" think was emergent and not enforced at all, but it was a bit implicit that if possible, you ask Bill his advice before rewriting a function of his model. The lead dev was still nosing around everywhere and had authority to call a piece of code defective and impose a rewrite.

One of the important function of the project manager is also to communicate clearly with upper management about what the team is and can do. We were working on a product that was not deployed yet and our priority was to release a functioning version ASAP, so redundancy was irrelevant. We had n features to develop, assigned to various developer. When one developer is on holiday, their features did not advance. We worked around it thanks to our modular architecture.

It meant that sometimes, <urgent but usually irrelevant feature> was impossible to code before <meeting with potential client next week>. I scheduled or denied those. This team and project structure is optimized for fast development with an heterogeneous team, not for reactivity.

There are infinite ways to organize teams so your concerns are addressed. For example, you can have primary, secondary, and backup developers for each component of the system. That keeps you bus factor down and makes it more clear what the progression of responsibility looks like.

But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.

> That keeps you bus factor down

Small nitpick: I assume to wanted to say this keeps your bus factor up.

Oh. Right! Thanks.

I understand your concerns. That never became a crisis for us because of a few reasons. 1. An individual rarely deployed their stuff right before vacation (because of this reason). 2. We had an exhaustive QA process (full regression had to pass before deployment). 3. Everyone on the team was senior and could debug other people's code quickly and easily. 4. Other people's code wasn't crap (see #3). 5. Everyone was familiar as to what the other modules were doing.

Just to note, this wasn't a small system. At least a million lines of code and it was a decision support system. Bugs could theoretically cost lives (at least that's what we told ourselves, but it was kind of a stretch).

This was in a software shop back when we cut and distributed CDs. We had a 3 month release cycle which really enforced #2. I understand this is a lot harder when you are doing 2 week release cycles in Agile or something. With 2 week cycles, full regression for every release kinda goes out the window because there isn't time. (one of the down sides to Agile).

> As a manager, one of my main jobs is ensuring that the team's bus number is always above 1

Bus number of 1 would be nice to experience for once, I have yet to see a team with a bus number above 0...

Reply on news.ycombinator.com