Pimply youth

Last week I spent some time back with the guys on the refactoring project. Things are going well for them and, apart from a few minor transgressions, they’re sticking with the process that we put in place when I was with them on a regular basis. The project is currently suffering from a slight lack of technical direction; they have a new guy on the team and he’s enthusiastic to try ’new’ things and nobody is currently restricting the things he is allowed to try…

Reasonably inexperienced developers who have read a lot of books can be more dangerous to a project than inexperienced developers who don’t care about their own technical development. A little knowledge can be a dangerous thing, and all that… Unchecked, an enthusiastic developer with lots of new ideas can wreak havoc on a project as they try and incorporate all of the things they’ve recently read about into the project they’re working on. The team on the Refactoring Project is generally pretty experienced guys but the team structure is very flat. In general everyone just gets on with their own stuff and works around the other guys and their stuff. This approach seemed to work fine for them when everyone was around the same level of experience.

Recently they’ve added new blood and the new guy is working in the same way as the experienced guys only the things he’s doing are, well, less experienced… He’s been making some somewhat dubious decisions, for the best of reasons… The rest of the team have mentioned a few things to him, suggested this and that, tried to tame him, but he uses his new found book knowledge to baffle them and eventually they give up and choose an easy life…

I’ve seen this kind of thing before; new developer reads the patterns book and suddenly everything has to be a singleton (if ever there was a pattern that should have come with a big yellow warning label…); they google around and find Guru Of the Week and suddenly the code gets all pimply.

The problem is not that they’re using ‘advanced’ idioms it’s that they’re simply using them despite the fact that they may not be appropriate. They know how to use the feature but not where to use it… Knowing that you can use the pimpl idiom to provide a compilation firewall is all well and good; knowing when it’s appropriate to add that level of complexity and knowing how to add the idiom without creating memory management bugs is another thing entirely.

I see this problem time and time again. Production codebases being used as training grounds for developers with no clue as to how clueless they really are. There’s a time and a place for putting new tricks or techniques into practice and that place is not on the main project that needs to be delivered next week… All too often the management responsible don’t know enough about what their developers are doing to see this happening. New techniques, idioms and even languages are used simply because they’re new and cool, not because they’re actually adding value to the project…

So, part of my job last week was to report on the ‘decay’ of the code base due to over enthusiastic use of inappropriate idioms in such a way that both the new developer and the management team responsible for the project understand the dangers and take more notice of the more experienced developers suggestions… I’ll be back with them in a month or so to see if they’ve heeded my advice…