Saturday, April 5, 2008

Square Peg?

Recognizing bad code and refactoring it is one thing (see and but, how do you address a team member who is writing code that is a pain to deal with? First, consider that possibly, the developer may not be as dysfunctional as he seems, after all, ...

  • In Heaven, the cooks are French, the police are English, the mechanics are German, the lovers are Italian and the bankers are Swiss.
  • In Hell, the cooks are English, the police are German, the mechanics are French, the lovers are Swiss and the bankers are Italian.

    Luckily, software development teams aren't quite so stratified but, there can be times when the contributions of a developer need to be addressed.

    The best approach to this problem that I've seen does not focus on the quality of the developer's work. Instead, the approach is to show the developer the problem and give him the opportunity to show how how his work fits the needs of the team. Perhaps you'll learn his work is sufficient or you may find that although the work isn't suffcient, that the developer is doing what he was assigned to do.

    The third possibility is that the developer will see that indeed, his work doesn't fit the requirements of the team and he'll change what he is doing. Presenting the problem not as "You're wrong" but rather as "This is what the team needs from the software you are developing" gives the developer the opportunity to immediately begin making a positive contribution to the team.