Debugging managers

The other day I was debugging the application I work on. At some point looking at the debug window in a “context free” way I realized that there is a whole lot managers in it and what I’m doing is basically debugging managers of managers.

It’s no that I think it’s a bad design or these classes are badly named (they could’ve been better, though). And it’s not that I think this structure is too complicated, after all there are only three levels of managers in the picture (actually more).

What drew my attention was the idea that choice of class names is influenced by organization, its structure and its language. The place I work at use model like: coding monkey –> manager –> superhero manager. Where the last two stages are obviously bound to be attractive. Now imagine how many times you can read the word “manager” in code (fields, parameter, local variables) given the huge number of manager classes. Admittedly it’s not very useful idea, since I can hardly imagine how one could benefit from it.

As the Conway’s Law (which sound like “any piece of software reflects the organizational structure that produced it”) the idea of code being influenced by corporate language boils down to the fact that it’s people who produce software and they inevitably leave traces.