[thetmkay]

Could you explain how you get around the knowledge silo problem? Fungibility across the team is useful for resource allocation and can prevent bottlenecks - for example if a part of the codebase is higher priority or someone is ill or on holiday.

Loose partitioning seems like it would work if either:

1. the partitions were similar/simple enough for other members to grok easily 2. the documentation and code sharing were thorough and extensive

I don't know how feasible it is to rely on (1) and (2) seems like it would cost an investment in time that would subtract from the efficiency gains of partioning. If it is (2) what are the exact reqs/mechanics for docs/PRs that seem to have worked?

I'm especially curious as "how to structure development teams" is something I am beginning to actively learn about.

[jfoutz]

> Could you explain how you get around the knowledge silo problem?

IMHO, you can't. Imagine either extreme. In one case, everything is so well documented and test, and every developer has all of the necessary domain knowledge for every problem. In the other case, everyone is hyper specialized, and hasn't the foggiest idea what's happening on the other side of the interface they're calling.

The reality is, some people like small, diverse problems, and want to make small-ish changes over a big codebase. Some people like big, deep, gnarly problems. Furthermore most people vary from week in their productivity and quality.

It's a puzzle. each person is a tile, and you have to cover the whole problem with tiles. As people produce solutions, you have to consider, how much of the codebase could be handled by your most jr developer. Does the code need to be so simple anyone can work on it? Generally, yes, but not universally. There can be some scary parts of the code where, perhaps only half the team can be trusted to mess with it. The thing that sucks, is when you have a scary corner of the code that only one person can handle.

Both extremes suck. Be judicious about how much scary code you're willing to tolerate. All i can really offer is hand wavy advice. I don't have a formula, and i kind of think a formula can't exist, because there are so many constantly changing factors. Time pressure, turnover, inconsistency, changing needs, there's just a ton.

Trying to match people with stuff they like to work on, and not being afraid to pull people back when they start getting a little too clever seems like the best heuristic.

[wiz21c]

I like this answer. I'd say it differently : provided you work on some non-genius-level code like your average (no disrespect!) website, the problem will be more human than technical. Figuring who's good at what is quite connected to who likes to do what and how they want to do it (small fixes, small projects, long projects,...). Some people are super good at coding batches but will just stop working if they have to interact with a non-cooperative person (say, a customer). Other will do marvel at understanding one's need but will make very approximate code. Some will like to review someone else's code but will hate to be reviewed. Some will need constant attention or else they'll drift to facebook, youtube, whatever.

Managing people is so much more about soft skills than technical ones. I've managed people who learned to code alone, people who learned at college, or university level, up to phD. Each of them is different.

The only thing I don't know how to do is : how to motivate people who work-for-eat, who are not passionnated about their job. I have no idea and it drains a lot of my energy :-(

[thetmkay]

Thanks for the response, I appreciate the pragmatism in your advice. As with everything it seems to be a question of balance and circumstance.

[0xbear]

For as long as we can't read each other's minds there will be "knowledge silo" problems. And yes, all code and all documentation is shared. For sharing designs, we use google docs. For documenting code already written, we use markdown and jupyter notebooks where things are hairy or test data has to be synthetic.

Note that I said "loose partitioning". Team members are expected to be able to make forward progress on their own in areas they don't work on as the main thing they do, but review code for. Maybe not at the same speed, but at least they can fix minor issues and bugs. Anyone can change anything in the code base as long as the original author of the design approves the PR. The understandable desire for territoriality is ignored as a matter of policy.

And none of what we do could be described as "simple". It generally ranges between "insane" and "frustrating", sometimes both.

[thetmkay]

Thanks for the response - interesting set up especially with the use of Jupyter notebooks.

It seems to be a case of always having a solution that's "the best of a bad bunch" rather than a "good" one. Like Churchill on democracy.

[0xbear]

We simply have too much going on to sit around and try to perfect a solution. I don't even think it'd be worthwhile even if we had all the time in the world. We see what works, if it doesn't work we change it. We also don't let bureaucracy interfere with forward progress. 80% of the solution is usually good enough. We aren't in it to sell books about management.

[liberte82]

Silos are okay as long as they're managed appropriately. The purpose of breaking apart silos is to avoid risk to the company if a person leaves or is required elsewhere, not just to spread knowledge for its own sake.

On my teams I always ensure that there are 2-3 people who can cover every module. More than that and you start getting inefficient, the knowledge becomes shallow. Less than that and you're taking on big risk.