Okay, another stupid title. Example please.
At the most recent meeting of the Chicago Alt.NET group, the second-half 'free-for-all' discussion we talked a lot about actual experiences that people had with agile development. The concept of pair-programming came up more than once, and amongst its benefits (Monty Python reference) was the idea that you can help spread knowledge throughout your team by continually allowing different developers to work on particular blocks of code (that's a poor description really, but hopefully you get the idea).
Now, this benefit isn't something that can only occur within agile development or only with pair-programming. Even in a waterfall-ish type development environment, you can get this benefit (though perhaps not as easily) by assigning different developers to subsequent projects that extend a particular block of code. I say "though perhaps not as easily" for the fact that, in time-tracking tool driven environments, the previous developers with the already acquired knowledge are often times not allowed to 'officially' work on the subsequent project. As a consultant/contractor, I've faced this often enough. There is someone in the company that worked on, or even built, the block of code that I'm assigned to, but I can't expect them to work in an engaged fashion with me on the subsequent project, because the time-tracking tool says they have to work on other things.
To give a concrete, but vague enough, example, consider auditing. Seemingly every company, at some point, seems to want to add auditing functionality to an area of code that wasn't initially built to handle it. And, seemingly, every company decides to hand-roll its own custom solution. So, Person A builds it for a sub-set of the application, and then after that is successfully completed, it is decided to expand it to another area of the application. This gets assigned to Person B (in this case, me), who played no role in the initial construction. In a pair-programming environment, I would at least be guaranteed a piece of Person A's time, whereas what typically happens, you have to figure out the custom solution as best you can, and then ask one-off questions when you get stuck. Also, without pair-programming, you have a greater ramp up time where you are stuck by yourself trying to 'figure it out as best you can' with limited support.
Side-note: everyone has worked with the stereotypical prima donna who insists on owning a particular code block, but more often than not, or at least sometimes, Person A is glad to have another person working on it, because it frees them from being the 'go-to-guy' every time a problem occurs down the road.
By spreading the knowledge around, you minimize the 'what happens if Person A gets hit by a bus' problem, and make it easier to assign future work down the road.
All this is well and good.
But what about true subject matter expertise? The sort of thing that can't be spread around?
Again, I'll use a couple of examples.
In the last few years, I've worked for clients involved with (among other things) oil refineries, telecommunications, and finance. Now, I may not be very good at certain things, but one thing I can do is, assuming nothing else than looking at the code, know that if Widget A comes into play in the code with certain properties, then given certain conditions, I can tell with some certainty what Widget A and its properties will look like after it goes through a code block. I may not know exactly what Widget A is, but I can fake being knowledgeable by reading the code.
But, I can never replace a true subject matter expert who is also a coder in these cases. Working in financial institutions, if someone says "we are thinking about extending this code to handle quants," my immediate reaction is "What the hell is a quant? Isn't that the airline with the koala bear mascot?" To be honest, I'm not sure I've even spelt 'quant' correctly. I've been a member of teams with people who know what they are, and have sort of glanced at documentation that explains what they are, but it's way more complicated than anything I will ever really understand. Because of this, I can never be able to know in that 'in a glance SME talent' way if the code I'm working on avoids the unspoken potential issues that someone with real SME knowledge could have. Even with pair-programming, I can never rise above my 'Widget A' ability.
Since there a *lot* of talented developers with financial SME ability, let me use 'Telecommunications' as an example.
I worked for a company that had an application that verified the part list and installation order of a telecommunications network. So, the company would be hired by others to build out and/or replace their existing telecommunications infrastructure with the company's equipment. The application would take in as inputs what the field engineers had determined, validate that no errors existed, and place the order (roughly, it's been a while).
The 'Quandary' is this: arguably there was one developer on the application who was a true SME (personally, I'm not sure that he was, but let's go with it). There is, was, and never shall be any possibility that I could ever have gained anything even close to SME talent here. In a previous life, I helped manage the telecommunications network of a small company, so at least to a certain extent, I knew at a really high-level the types of parts involved (which is why I got the gig, since they couldn't find a lot of people with even high-level knowledge), which put me one step ahead of the game. But even with pair-programming, there was a ceiling to what I could know. So, in this case Person A would always be required on the application. In which case, except in a supporting role, the whole notion of 'truly' spreading knowledge is a myth.
And, it's also potentially harmful. The 'team building' concept is usually couched in terms of 'junior' vs. 'senior' (which to me is simply the difference between 'new guy who doesn't know the system yet' and 'guy who knows the system') but when it comes to true SME knowledge, it can't be shared. Unless you get a junior developer who is also an SME.
In the financial industry, this is probably (I think) more likely to be possible, but when it comes to telecommunications, the SME is the field engineer, and he doesn't want to be a programmer.
This is also a quandary for DDD and the 'ubiquitous language.'
None of this is to suggest that those who practice agile development get it wrong more than other types of development. I think it is endemic to the field.