A couple days ago I saw a post (EDIT:  the post was removed) relating a depressing situation that sounded sadly familiar to me and I have to respond.  The author relates a story of getting to the end of a time-constrained project and realizing that the other developer’s code is bad.  I can easily relate to the author’s plight because I’ve been in the exact situation at least twice.  My diagnosis for both the author's current project and my past experiences is simple.  The technical lead (me) failed to lead the technical effort.

My problem was that my first official developer job was in a completely dysfunctional organization.  That’s actually a mixed blessing in a way.  You can get more opportunities because it’s easy to stand out, but it stinks in the long run because you don’t get to learn the right way to do things very often.  I was by far and away the most productive coder and the guy with the design vision, but I didn’t know squat about leading or coaching other developers (plenty of people will say I still don’t).  I was forced (ok, I basically seized the role when nobody else was looking) into a technical lead role on my very first significant project.  I’d never had any role model for being a technical lead, much less a good role model.  I made the typical blunder that many first-time technical leads do.  I put the headphones on and hunkered down with what I thought were the most difficult pieces of code and did them.  I gave the other developers what I thought were easier tasks and generally ignored them as much as I could. 

I answered questions here and there, but I wasn’t that involved with their coding.  When I finally got around to looking at their code I often didn’t like what I saw.  I rewrote several pieces of their code behind their backs at the last moment.  I essentially wasted the efforts of the other developers.  Two of the developers was truly incompetent but the other two were bright folks that had even less experience than me.  One of the developers was so bad that I started calling him the “Canary” when the “Reduction in Force” rumors started when the tech industry crashed in 2001.  The project was very successful, but could have been much less stressful if I’d invested much more time into the other developers.  They probably would have gotten a lot more out of the project, too.  One of the reasons I think that shop was and is so bad is the complete lack of coaching for technical folks.

Losing Strategies

• Drive by shootings -- I mean code reviews.  I’m sure code reviews are useful somewhere, but I’ve never been in one that wasn’t either a complete waste of time or a source of resentment.  Relying on code reviews to catch bad code after the code is written is inefficient and just plain stupid.  Code reviews can easily turn into a case of the prosecution versus the defense.
• Poor or infrequent communication between the technical team members.  On a couple of occasions some of the developers on my team were on the other side of a cubicle farm.  Co-locating a technical is a no-brainer.  I wonder how much inefficiency exists in large IT organizations where they don’t co-locate development teams.  Technical documentation like design specs are a poor form of documentation.  The only good thing about technical specs is that they’re more durable than a conversation.  Tossing specs over the wall to a development team and walking away doesn’t work.
• Detailed work assignments.  My experience has been that feeling is that the more detailed work assignment you give another developer; the crappier code comes back to you because they will mechanically implement your design without thinking.  I’ve got a case of this on the system I inherited when our very bright boss gave some specific design advice to the team building the system that this team followed without question.  The advice wasn’t necessarily bad, but there were definitely simpler alternatives to what was built. 
• I design, you just code.  Even before I had ever heard of XP I always believed that coding, design, and architecture are too interdependent to be done by separate people.  Developers can internalize a design strategy better if they contributed to making the design strategy.  Over and over again I’ve found that it just doesn’t work to give someone a detailed design without a lot of verbal and whiteboard communication.  I think there’s also an issue of developer pride and ownership.  I think coders do a better job when they feel some sort of ownership stake in what they’re coding.
• Ignoring the other developers to concentrate on my work.  I have to constantly remind myself to focus on the team’s velocity as opposed to my velocity.  I still think that I’m most effective early in the morning when I’m heads down into code with zero interruptions, but that doesn’t help the other developers.  It’s not just a matter of trusting the other developers – but that is often an issue.  It’s also about talking over the design, looking for duplication, and creating a shared vision.

Winning Strategies

• Involve every developer in the design work.  Over and over again I’ve found that developers have a better working understanding of a system’s design when they’ve been involved with creating the design.  Many agile practitioners are hostile to design sessions because of a fear of speculative design or an assumption that it’s jus wasting time (but the agile community is also mellowing in recent years).  I think design sessions in front of a whiteboard with the team is a create way to get the team on the same page.  Most agile projects involve a “tasking” activity to break down user stories so they can be estimated in iteration planning.  The “tasking” meeting is essentially a design meeting.
• Pair programming has been very effective in my experience for communicating design knowledge throughout a team.  It’s also a great mechanism to coach other developers.  Pairing can be used as an ongoing code review to eliminate problems more rapidly without the nastiness of a formal code review.  Bad coding practices can be caught very quickly.  On a project last year most of the other developers were Java and GUI guys that hadn’t worked with database or persistence code very much.  Because we were pairing I noticed that they weren’t attending to connection hygiene very well.  I caught the issue very early and explained why it was important to manage database connectivity.  Waiting for a formal code review a couple months into the project to read other people’s code would have allowed that problem to fester.
• Collective code ownership.  Nobody works in a silo.  Every developer, at least in a small team, should have some visibility into the entire codebase.  Determining and enforcing best practices can be a lot easier when people are rotated through the code.
• Think out loud.  This is purely an exhortation to me because I never do this well enough.  If you’re one of the primary people doing design on project, talk about your design thoughts all the time.  Involve your teammates as much as possible.
• Coach the other developers.  If you’re the senior most developer your most important contribution may be the coaching you give other developers, not necessarily the code you write.  Helping other developers is an investment in your team and organization.  Besides, they undoubtedly have something to teach you too. 
• Co-location of the developers and the rest of the team.

You could easily argue that the ability to communicate ideas to other developers is one of the most valuable skills a lead could possibly have.  I don’t think anybody can be a technical lead without good technical skills, but not every strong developer is fit to be a lead.  Heck, I’m the veritable poster child for this.

Of course, you’re always going to have trouble if the ratio of “needs coaching” to “able to coach” gets too high.  The idea that all you need is one smart guy on a project to tell everyone else what to do is a nonstarter in my book.  No process or goofy accreditation effort, be it wild-eyed XP, UML out the wazoo, Six Sigma Ninjas, or CMMI Level Umpteen, is ever going to change the fact that producing good software requires good people.  Some people want to be the bright shining star of an organization, and the easiest way to do that is work with bad people.  I’ve gotten to work on a couple of very strong teams at both my current and previous employer.  That’s been vastly more fulfilling and less stressful than being “the” guy on a weak team.