Bugs:
Programming generally involves taking many vague or abstract concepts and then tying them together to build something great. Judging developers based on the number of bugs in the code perhaps one of the worst ways an organization can shoot itself in the foot.
In a world where everything is so pro-Agile, there is no blueprint to follow. We're not building houses -- the purest form of waterfall model possible -- where we know every stud must be 16 inches apart because that's how we built the last 15 houses. Every software project is fundamentally different in some significant manner from other software projects.
Thus, bugs are just a fact of life. All software will have bugs, because many times developers are tying things together that have never been tied together before. Don't base performance on bugs, unless your goal is to demoralize and beat down your team.
Speed of Coding:
Some developers can code very quickly, but then 6 to 12 months down the road; suddenly, the progress comes to a grinding halt due to all of the shortcuts and bad decisions made in the code. Programmers aren't typists. You don't measure success by how quickly they can spew code into their editor.
Other developers are methodical, patient, and detail-oriented. They take the time to think about what approach will ensure the success of the product. Their decisions ensure that the product can still be supported years from now. They make sure that when one part of the system changes there isn't a domino effect created that reverberates through the entire codebase, knocking everything else out. Their code is well-commented, readable, engineered, and easy to maintain.
I understand why we as project managers want to measure this, but we must understand that this is a very delicate, possibly immeasurable balance, and it involves good judgement and decision-making by the technical people on the project.
Developers are generally paid on salary because their jobs involve the ability to make decisions and judgement calls, not produce little round widgets on a minimum wage production line.
Adherence to Requirements:
Software development is a creative process. It's also an engineering process. The engineering process comes into play when the developer has to make sure he or she understands what it is that should be built. Using logic, good documentation, sometimes formal methods and planning, a developer should be able to have a clear picture of what he/she must build.
The creative part comes into play with the actual solving of the problems that will ultimately arise during the development process. This sometimes occurs in other fields as well, like in construction. Perhaps there is some reason why the last two studs can't be 16 inches apart, so some creativity must be put into finding a safe and sustainable solution. With software, sometimes developers run into walls, and he/she must find a way around that wall by taking the things he or she knows about several different programming concepts and then bring them all together to come up with a great solution.
Now, the creativity part of software development doesn't mean the developer should go off an build whatever he or she wants to build; instead, the developer must still adhere to the requirements. The creative part is in the approach to solving the problem, not the actual problem itself.
With that said, sometimes engineers come up with creative ideas that can enhance the product. However, whether or not those items are implemented depends solely on who the product is intended for. At a startup, the engineer is likely to have a lot of freedom to innovate and create something that will instill passion in people. On the other hand, in a big corporation building custom software for a client, the goal is to deliver what the client wants, and that may leave little room in the requirements for unsolicited change.
Summary
In summary, the first two points are items that just don't make sense to measure. Bugs are a fact of life. Just look at them as unfinished features or part of the enhancing process. Speed of coding may not be a function of project success because coding is an engineering process, not a manufacturing process. Finally, requirement adherence may change from project to project and may not be measurable or important in some projects.
Instead, focus on evaluating the people. Is he easy to get along with? Does she help motivate other team members? Does she help collaborate with the team and generate problem-solving ideas? Do you trust this person to deliver what he or she says he's going to deliver. When bugs are found, does he take responsibility and passionately dig in and fix the unfinished feature (bug).
By it's very nature, software development is a subjective process, and you cannot use objective evaluation criteria to evaluate positions such as this without undermining yourself, your team, and your organization.
