As I've mentioned before, I am not an expert in this area, but I am really passionate about teams working well together and producing high quality code. And I think I have some pretty good ideas. Although I am not a manager, it's easy to see that managing a team of developers is really hard. Not only because of developers having split personalities, but also in evaluating their productivity.
Why Evaluate Developers?
I think it's safe to say, that just about everybody wants validation in their lives. It's important to know that what you're doing is not only appreciated, but also valued. Sometimes verbal recognition is sufficient. Giving a "pat on the back", especially in front of other team members, can often be a major pick up for a developer. But that doesn't work long term. Things will come up. Raises, bonuses, and promotions, are all things that will likely need to be discussed at some point. It's important to be able to measure an individual's productivity when evaluating these things, and providing feedback, especially if they need to improve on something.
What's So Hard About That?
It's fairly easy to evaluate something like sales for example. You can clearly see how much revenue a salesperson is generating at any given point. From that you can set first-quarter goals, second-quarter goals, etc. Also, there are a number of great tools for measuring the productivity of teams and projects, however, with individuals, there is a huge number of variables when it comes to measuring productivity. The number of lines of code? The speed you type at? The business value of the project you happen to be assigned to? Application development is an incredibly complex process. It involves both detailed analysis, and on-the-fly creativity. It sometimes even involves starring at your monitor for a few hours. This makes it nearly impossible to measure objectively.
What Can We Do?
This is where managers are left with a major challenge. They somehow need to be fair, while evaluating and measuring subjectively. Can you do that?
There really aren't any objective measurements, so measuring subjectively is all you have left. I guess you could continue to not measure, but I think that leads to unguided team members. That's not fun. I believe managers do this subjective evaluating anyway. Again, I'm not a manager (yet), but I know I would do that. Maybe not totally on purpose, but it's safe to say managers are able to look around the room and know who the top producing coders are. Who would you ask first to fix a critical bug in the system? If it needs to go out yesterday, who's best to jump on it? You know who is more valuable to the company. You've evaluated it, or "you just know". So, what are you considering?
I would suggest managers actually write down the things they think make those "top coders" their "top coders". Have a "formal" subjective evaluation process. Essentially a checklist for evaluating productivity. Some of these involve have standards set by the team, but that's for another post.
Assuming those standards are in place, here's what I have so far:
- do they produce code at a reasonable pace?
- is their velocity on bug fixing sufficient?
- are they dedicated to their role?
- are they committed to delivering on time?
- are the committed to the success of the team/company?
- Attention to Quality
- does their code work as designed?
- do they adequately test their code before calling it 'done'?
- are there minimal bugs reported against their code?
- do they write unit tests for all their new code?
- do they follow the Boy Scout Rule and leave code cleaner than they found it?
- System Knowledge and Usage
- how well do they understand the code base they are working with?
- do they take responsibility for the team's code base, always trying to improve it?
- Adherence to Coding Guidelines and Techniques
- does the developers code meet coding standards?
- do code reviews reveal minimal issues with their code?
- Learning and Skills
- are they constantly learning and improving their skills?
- do they show a passion for software/application/web development?
- Personal Responsibility
- do they first assume the error is in their code?
- do they understand that they are solely responsible for their code working?
- do they take pride in their code, making sure it's clean, easy to read, and maintainable?
Again, these are very subjective measurements. They require the manager to make very subjective judgments. But I would think that they are in a management position because they have good judgment about these things. And, let's face it, they're probably doing this already.
By simply writing these things down and discussing them openly with individual developers, you can not only evaluate productivity, but also provide feedback. Most of these questions could have "yes" or "no" answers, but they can all lead to further discussion. These discussions can help less productive developers know where they need to improve, and help more productive developers understand where they might be headed within the company.
While subjective evaluations may not be ideal, they are far better than no evaluations.