The problem - Lately I have been working with a lot of developers that seem to be taking object oriented programming/new concepts/etc.. to a level that may not make sense. Developers read new concepts/articles and they sometimes think that is must be implemented that way when in fact that is not the case all the time. Since I run a software development shop I constantly see this happening and it sometimes posses some problems that I wanted to list out.
1. Difficult to maintain - A developer may read an advance article and then try and implement that algorithm/concept. Then they become the only developer that can maintain that code. As a manager this can be frustrating and expensive (not to mention dangerous if that employee leaves). Prioritizations become tougher since you always need them to work in that area (unless you have time for cross training which is not always the case).
2. Not Applicable - Just because an article mentions a concept, does not mean that it is applicable to your environment. Developers need to understand when to use certain concepts and when not too, and base that partially on the environment they are working in. It is one thing if you are working for microsoft but then what if you work for a company like mine where you have 3-4 developers at any given time and the rentention rate is less than the change in my pocket...and I have no pockets.
3. Not tested or proven - Another thing that has happen is they take an algorithm/concept and implement only to find out later that their were flaws or performance issues with it. I am always careful of introducing new concepts unless it has been tested and validated.
There are ways to reduce the risk and still use the latest and greatest...
1. Document Document Document - Make documenting the code a priority. Not just in the code but in a seperate technical specification. Once that developer leaves this will be the only thing remaining.
2. Peer Reviews - Having a developer present their ideas in a weekly or monthly tech meeting allows for other team members to understand the reasoning for the logic as well as have knowledge transfer at the same time. It is healthy to have technical debates on whether something should be done a certain way. this will reduce all 3 items.
3. Training - Sometimes the developer making things complicated is not really doing anything wrong. It is just that the other developers do not have enough training/knowledge to understand. Try and schedule group trainings and encourage your employees to get training on their own if the company can not afford it.
4. Read Read Read - Before implmenting new ideas and tehnologies make sure the you read as much reviews and backgroundas you can on the topic. Question whether it is needed at this time or even at all.