I have a few programmers under me, they are all doing very great and very smart obviously. Thank you very much.But the problem is that each and every one of them is responsible for one core area, which no one else on the team have foggiest idea on what it is. This means that if anyone of them is taken out, my company as a business is dead because they aren't replaceable.I'm thinking about bringing in new programmers to cover them, just in case they are hit by a bus, or resign or whatever. But I afraid thatThe old programmers might actively resist the idea of knowledge transfer, fearing that a backup might reduce their value.I don't have a system to facilitate technology transfer between different developers, so even if I ask them to do it, I've no assurance that they will do it properly.My question is, How to put it to the old programmers in such they would agreeWhat are systems that you use, in order to facilitate this kind of backup? I can understand that you can do code review, but is there a simple way to conduct this? I think we are not ready for a full blown, check-in by check-in code review. 
How to make sure your company doesn't go underwater if your programmers win the lottery
teamwork;knowledge transfer
How to put it to the old programmers in such they would agreePresent the problem openly to them, of course in such a way that they don't see it as a threat, rather an opportunity to make the team and project work better. E.g. I would like to have other people know what you know in case you get fired is obviously a wrong approach :-) I would like to ensure the smooth working of the project even if some of you goes on holiday or gets ill is much better.Usually the developers themselves experience the problems themselves every time some of them is on holiday and they need to cover for him/her. Moreover, good developers feel responsibility for the project they are working on, so they will probably agree with this idea. Still, give them time to discuss and (hopefully) commit to the idea. Also, allow them to have their say on how and with whom to share their knowledge inside the team. It may turn out Joe feels OK to work (and share his knowledge) with Jim, but not with Jack etc.What are systems that you use, in order to facilitate this kind of backup? I can understand that you can do code review, but is there a simple way to conduct this? I think we are not ready for a full blown, check-in by check-in code review.In our team, apart from code/design reviews, we useRotation of tasks and responsibility areas between team members (each of us has his main areas of responsibility, but every now and then, we do tasks in an area better known by another team member)Face-to-face knowledge transfer sessions (usually when the above tasks require, but also before someone is leaving the team)Team/project wikiCode review in itself may not be enough as in a lot of areas there is typically a lot more for a developer to know than what is directly readable from code. In other words, there is the domain model as well. You can read what the code actually does, but without the model, you won't know why.