In a blog entry from the start of the week Mark Masterson cited from the lessons learned document of a past project:
"Change the design / architecture to reduce reliance on the divas"
That reminds me of a former client of mine who used to say
"If you've got a genius in the team - get rid of him"
At first that's rather sad, but after a while - and with changing responsibilities - I came to realise that there can be situations (actually lots of them) where the advise is absolutely sensible.
It can be sensible because most developers are of average capabilities!
After all - that is exactly what average means.
Therefore the probability to have "above average" developers declines with the size of the project (and the organisation) simply because of the definition of average.
Even if all (or at least almost all) the developers in a certain team are "above average" (e.g. compared to some outside group of reference developers) most of them will - by definition - be of average skill within the team. That's where the "get rid of the genius" sets in.
If one of the persons on the team is way ahead of all the others - lets say she is a specialist in compiler construction - their advantage can become a disadvantage for the team as a whole. For those "geniuses" TSTTMPW (The Simplest Thing That Might Possibly Work) probably is quite different from the things the rest of the team perceives as "simple".
Configuration files are a good example - while plain text with very little syntax is the "simple" thing for most of us a specialist in compiler construction wouldn't mind using a sytax that is "syntactically a little richer" to gain simpler implementation. He might end up with a configuration language like sudoers' - where guides to the grammar (defined in EBNF) and the grammar's grammar are provided in the manual pages just to give the average user a chance to understand sodoers.
Actually I worked on a compiler project myself way back in the 80ies and used to be kind of fluent in BNF, but figuring out sudoers still took me a while. And judging by the amount of
<username> ALL=(ALL) ALL
(basically: allow <username> to do everything he wants as root)
that I've seen on other peoples Macs not many of them go to great depth deciphering the format...
Back to projects: Of course the idea to get rid of every smart person in the team would not be the best option - unless you want the project to fail.
But the "geniuses" - or, to be fair: those who have advanced knowledge and/or experience compared to the rest of the team - have to be handled carefully. Only for very isolated tasks they should be left to work it out all alone.
For the rest of their work they ought to work closely together with other team members as long as their personality allows them to adopt their ideas to a level thats appropriate for the whole team. Should the latter not be an option then option one is valid again of course - the team should get rid of 'em.
But in my experience that is seldom necessary Most geniuses are quite willing to agree on a sensible level of "simple" as long as their is a sensible discussion.
So after all it no so sad anymore. The bottom line of my job is not to get the "best" possible solution but to make the team as a whole as effective as possible
_MM_
