As we make contact with various software companies and professionals, whether as customers, co-workers, friends or partners, we made an habit to ask how developers are sharing knowledge in their companies. Our initial question is almost always the same: "Let say that one of the developers is stuck with a technical question, what does he do ?", and by asking it again and again, we start to see some "patterns of knowledge exchange" emerging.
The Human Hub is a developer that has been in the company for a long time. He has worked on most or all of the companies projects, and with almost everyone. While being there for a while is important to play that role, it is not sufficient: he also needs to have a function and personality that imply many interactions with his colleagues. In the proposed situation, while the Human Hub does not have all the answers, he typically knows who to ask the question to, so people came to him to be redirected, thus reducing the "probing" to only one trial.
This situation is quite efficient (reducing N maximum probes to only one), but heavily dependent of the Human Hub presence and time. With more than ten people, risk is big that he will spend a significant part of his time doing this job - which while being useful to the company may not be related to his aspirations or schedule. The departure (or promotion) of the Human Hub would also be a difficult situation to manage.
This is the professionally version of the Human Hub: the company devotes resource in the form of one or more person dedicated to managing the knowledge of the developers (possibly split among technologies if the company is really big). This means that someone (and probably some tools) have the information about who knows what technology. While very useful in many situations (far ahead of the stated problem), it is something costly that only big companies can afford (starting around 50 developers), and the required precision is difficult to achieve (if I am stuck with a problem with the Spring Security Java library, or with Sinatra, I do not just need "a Java developer" or "a Ruby developer", but someone with a very precise skill).
Open space yelling
Typical of smaller teams, this is just looking up and asking the question in a loud voice. While efficient for the asker (he will most probably have an answer or someone coming up to help him), it de facto probes everyone in the office, thus interrupting all the work of all people.
While the interruption is short, most people need between 15 and 30 minutes to be back at full speed in what they where doing. The numbers quickly add up if you have five or ten developers, as each add to the number of people interrupted and to the chance of interruption.
Loosely coupled teams
Everyone one try to build "loosely coupled systems", that is, big systems that are nicely split in various part with as few interactions between them as possible, or at last very precise and well defined ones, thus sparing the developer working on component A the necessities to know everything about the component B that he uses.
The loosely coupled team is an extension to this at the person level: each developer (or small group) is mainly working on one unique component, which he knows well. As this repartition is known to everyone, if you have a question about component A, you know who to ask.
This work better with rather stable teams (not too much turnover, or reorganization or change of responsibilities). One of the downside is that everyone is a sort of Single Point of Failure (SPoF), in case of departure, sickness or simply holidays.
Make it again
While not applicable to all kind of knowledge problems, one possible answers is to not look at who's been doing something similar, but rather start something from scratch, using knowledge possessed by the developer (so bypassing a piece of home made code difficult to decipher or some library not known by the developer). This is a variation of the "I could do this better" syndrome when facing another person code. No one is interrupted, but at the end of the day, you got two working implementation for the same kind of problem, at best. At worse, you may end with a lot of very specific snippets, as no one is really looking to build the "company's way".
Not at all
This is some kind of null hypothesis: someone is stuck with a problem? Let him search, he will most probably find a solution at some point. Having seen both students and professional developers stuck for hours or days on a problem they lack the necessary skill to solve, I'm quite concerned of the result. In the best case scenario, the developer will learn something in the process, but at a great expense of time, and with a result that will most probably be sub-par.
How is it working at your company?
Those are most of the situations that we have seen. How it is working in your current or previous company? How are those problems solved?