The Smartest Guy On The Team

Does your software team have a "wiz kid"? A "rock star"? Have you been lucky enough to find that one amazing developer who seems to be able to solve all of your problems in ways so creative and clever that nobody else on the team can even keep up with his brilliance?

If so, you'd better fix that.

We've all heard the saying before, "What if Rob gets hit by a bus tomorrow?" (Or whatever his name is. I would have used a ____ instead of a name, but then this post would end up with a lot of ____s in it. There's two of them already, and they don't look good. So we'll call him Rob. I don't think I've ever actually worked with a Rob, so nobody should misconstrue this as an actual historical tale.) Well, if Rob is your superstar go-to guy then that bus should scare the hell out of you.

The problem isn't that you'd be devoid of Rob. The real problem is that you currently have Rob. And you let him run amok in your code. (Sure, he writes the code and has a certain level of "ownership" in the sense that team members should take a sense of ownership over their work, but as the business owner you actually own it. It belongs to you. And, ultimately, you are responsible for it.)

I am not suggesting that you shouldn't hire smart people or that all of your software should be farmed out to the lowest bidder in some faraway land. Quite the opposite. What I'm suggesting is that (and this may be difficult to hear) Rob might not be as awesome as he tells you he is. Don't get me wrong, Rob might be a very intelligent guy. But that doesn't mean he writes good code. He might even right very clever, even downright brilliant code. But that doesn't mean it's good code.

This reminds me of one of my favorite quotes:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian Kernighan

Writing good code isn't a measure of brilliance or cleverness or creativity. Code is a tool. It's a utility to perform a task necessary to the business. In general, developers love to see clever and creating things. We're kind of geeky, and we really enjoy things like that. So it's often difficult for us to tone it down when writing actual production-quality code, but tone it down we must. Because the bottom line for production-quality code isn't cleverness, it's pragmatism.

But I digress, let's get back to the case with Rob. Consider a scenario...

Manager: Have you finished adding that feature?
Not Rob: It's turning out to be more difficult than expected. The code in that part of the system is really a mess, and the slightest changes are introducing all kind of unexpected effects.
Manager: I don't think that code is a mess. Rob wrote that whole module himself.
Not Rob: Well, regardless of who wrote it, it's a mess. The effort to add that feature is going to also involve fixing a lot of what's already there.
Manager: Nevermind, I'll just have Rob do it. He's better at this sort of thing.

It sounds eerily non-contrived, doesn't it? The characters could take any number of shapes:

• Manager and Rob are old buddies and they'll be damned if anybody is going to tell them that their buddy did a bad job.
• Rob helped found the company as the go-to tech guy and everybody just instinctively calls on him because he has a lot of clout.
• Rob was a highly-paid consultant some time ago and the company never learned how to live without him.
• Not Rob is young and Manager doesn't believe that anybody young can ever be more right than anybody old.
• Manager doesn't know Rob, but knows that Rob was a legend when he worked there and Manager would rather bring him in as a consultant than have to deal with the mess himself.
• etc.

Regardless of how the drama between the characters has unfolded, the situation is the same. If Rob gets hit by a bus tomorrow, Manager is lost without him. Now, I've been putting down Rob quite a bit in this post, and that might not be fair. I'm just reacting (in a somewhat Pavlovian way, perhaps) to the Robs with whom I've worked in the past. Most of them were genuinely useless and drove any codebase they owned into the ground. Some, on the other hand, were genuinely good (even perhaps brilliant in subtle ways) and I hope I learned something from them. Of course, while I like to think I can tell the difference, it's clear that Manager can't.

So, when you have a Rob, what you have is one of two things (or perhaps both):

• Rob writes terrible code, he just somehow convinces you that it's good. Without your knowledge or consent he is amassing on your behalf a ton of technical debt. And someday you're going to have to pay that debt.
• Rob is employing coding techniques with which your other team members are unfamiliar or for whatever reason they do not understand. While Rob is, in a purist sense, "doing the right thing" by striving for better code, he is doing so at the cost of supportability.

Or, to put it another way:

• You need to get rid of Rob as soon as possible.
• You need Rob to educate and train your other developers.

Again, these two are not entirely mutually exclusive. One of my favorite examples of this sort of thing on a team is dependency injection. For whatever reason, most teams don't use any sort of dependency injection at all. Maybe the design doesn't call for it, but in many cases it really does. But what I've found is that most developers (many of whom have been developers for a very long time) simply don't understand it, beyond the buzz word itself.

So what happens when Rob takes the helm and re-factors everything to invert the dependencies? He may be doing a huge favor to the codebase, but if the rest of the team doesn't understand it then at what cost is that favor? Rob's being a cowboy, and he needs to slow down. He's doing something good, but he needs to do it in the right way. He needs to educate and train the rest of the team.

Of course, we haven't actually seen Rob's code at this point. He might be trying to do the right thing, but he might not be doing it right at all. The best case scenario in this situation is when he educates the team on what he's trying to accomplish and how he's going about it, and another team member chimes in with, "Ohhh, now I see what you're doing... But wouldn't it be better if you did it this other way instead?" Ding ding ding, now we have teamwork and collaboration. (It's nice to dream, isn't it?)

But we are rarely on that team. More often, at least in my experience, we're on the team where Rob is by definition right for no other reason than because he's Rob. And this is a very bad place for a team to be because... What if Rob get hit by a bus tomorrow?

So, I thought of an interesting way to test this for a team. (No, I'm not going to hit Rob with a bus. But you should be aware that I used to live across the street from an MBTA bus driver and I don't think I ever saw that man sober. So, you know, you take your chances.) How can we effectively simulate someone on the team getting hit by a bus?

Surprise vacations!

(Before I explain what I mean by that, let me first state that I recognize that this probably isn't a very good idea for a company policy. But it might just make for a very interesting and revealing company experiment.)

The idea is simple... Any team member who has vacation time available is permitted to take that vacation time any time and is not to notify the team until the day that vacation starts. Were you expecting Rob to come in to work today? Surprise! No Rob for you. So... What do you do now?

If your team dynamics are balanced, you're just somewhat shorthanded for the day. This is inconvenient, but you should be able to handle it. (It's not like you're the only business where this happens. Ever eat at a restaurant that was noticeably shorthanded that evening? Ever eat at one where you didn't notice? Which one had better management?)

If your team dynamics are not balanced, if Rob is truly indispensable for your company, then guess what? You failed, at least for now. But I have good news for you. Rob wasn't hit by a bus. He'll be back shortly. And in the meantime, you get to identify the specifics of where and why Rob is indispensable and come up with a plan to fix it.

Because you have a single point of failure in your system. And you'd better fix that.