[neandrake]

Where I work the same situation often comes up -- a developer may spend weeks doing research for a specialized function building prototypes, etc.

Ensure the specialized developer is doing due-diligence in defining and verifying the module works as intended and have others analyze its interactions in the larger system to prevent cascading failure, conforms to application norms, __is documented__, etc. Even if most others wouldn't understand the internals during review you will be taking steps to keep the risk localized. If the bus arrives and you lose the specialized developer then it's reasonable to assume another developer would need to spend nearly as much time to catch up on the research.

Otherwise you're responsible for making the decision to invest more developer time now in understanding the problem/implementation vs. later - a gamble at how much time until that developer leaves.

Taking over specialized/legacy code is part of the job. It can be painful but there are steps you can take to minimize that pain later.

[qb45]

> __is documented__

Documentation is indeed the name of the game. Few things are more frustrating than seeing a code do something and having no idea why.

I want to see comments, names of any clever algorithms used, links to applicable datasheets, research papers, etc. A short overview of the whole design is nice, too.

[maxxxxx]

The thing is they can document as much as they want. Often the implementation is faulty and not what the documentation says it is. This happens a lot in multithreaded code.