Real Effects of Cowboy Programmers

In my previous post, I talked about the perceived strengths and weaknesses of cowboy programmers. I described cowboy coders as isolated, shoot-from-the-hip, hardworking, and antiestablishmentarian.

Cowboy coders often write unreadable code. But it that a bad thing? When someone else needs to maintain the code, yes. When someone else needs to dig through an obtuse and confusing system to figure out which parts are the external interface, yes. When someone needs to look at a clunky, poorly-named set of interface methods, yes. But most often what cowboy coders have is unreadable implementations, which is mostly harmless. The output that matters most in team projects are (1) reliability, ie does it crash, (2) reasonable performance, ie as long as it's not abysmally slow, and (3) readable and understandable interfaces. If you know what a system does and the interface is clean, it doesn't matter what's going on under the hood. That's the whole point of encapsulation; hide the messy bits from outsiders.

Cowboy coders also rarely document. Yet this is a tenet of agile programming: code should be self-documenting. Parameter names, variable names, method names, class names -- all identifiers -- should describe what they are, semantically not syntactically. (This is one reason why I think hungarian notation is foolish; it focuses on something the compiler can do for you.) Variable names like "gc" and "q" and "theFileStruct" are horrible. If that's what any programmer on your team is doing, hit them with a stick. If their identifiers are well chosen, the external interfaces obvious, and the use of those interfaces clear, then again the lack of documentation is not a weakness.

Brilliant code rarely makes sense to other coders. Any brilliant person, scientist engineer artist or craftsman, is likely to be misunderstood. Not understanding them often isn't critical. In a team environment, the interface is what matters, and it's much easier to get a cowboy to make good interfaces than to try to force him to work like everyone else. He'll probably not do a good job, and the process will just piss the both of you off.

Loners can be brilliant cowboys or they could just be slackers. Be careful to not assume that someone that prefers isolation is actually getting something done. The best way to do this is to monitor checkins. Some good cowboys won't check in code for days, but when they do check something in their progress is obvious. Slackers might have the same lax check-in habits, but when they do finally commit what shows up is tiny. Slackers are a threat to your bottom line. Don't just tell them that you want them to check in more often; tell them that you're watching the volume of their check-ins. Slackers will either step it up and get work done, or find a way to quit or get fired. This is one of the important distinctions a manager needs to make about his employees - is he a cowboy, working diligently in the dark, or a slacker, surfing diligently in the dark?

Cowboys can also have an effect on the rest of your team. The best, brilliant cowboys might be reclusive but in my experience they haven't been anti-social. Slackers, on the other hand, are sometimes passive-aggressive or rude. Having a brilliant coder nearby is often an inspiration for the rest of the team; it makes them feel like they're someplace special. Beware of how the team views the cowboy. If the team respects the cowboy's brilliance, treating him like a misbehaving child can send a message to the rest of the team that you value conformity over performance - and that's what you'll get: a bunch of rule-nazis that do the minimum required and leave the building promptly at 5pm. This is the fine line of management: you want to give the cowboy room to do his thing without upsetting the rest of the team. Make sure the rules you impose aren't just to make you feel better; usually the purpose of a software team is to ship, not to measure code metrics. What matters are features and reliability. If you're getting those on a good timetable, be happy.

Your cowboys shouldn't be driving the rest of your team away. One of my favorite software-management stories is about a new management hire that refused to fire a problem coder that was pissing off other employees (driving them to quit). When the manager went to his boss, the boss fired him! Yet, after looking at the situation, the manager agreed with what his boss did. If a problem employee is driving others to quit, the thing to do isn't to coddle the problem employee; get rid of them!