[maxxxxx]

How do people handle reviews of highly specialized stuff? We have people who do stuff nobody else on the team understands or at least it would take them a long time of learning to do a real review. I look at a lot of stuff and check if it makes halfways sense. I can look at the coding style but I can't judge the overall design without spending many hours on it (which I don't have. Nobody else on the team has it either).

I am starting to think that pair programming may use up less engineering time than doing thorough reviews.

[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.

[nradov]

That's a management failure. The organization can't depend on a single developer being the only one to understand a module. What happens when that developer leaves, even temporarily? A competent manager will dedicate time to cross training so that at least one other team member understands everything, even if this causes a short-term productivity loss.

[maxxxxx]

That sounds good but in our case that's really not feasible. If a certain developer leaves almost anybody in the team can take over his work in a few weeks. But nobody has the team to stay up to date all the time. We would have to staff up quite a bit. This would be nice but it ain't gonna happen.