Having to set objectives for developers, even though objectives don't work [closed]

Answer 1

what approach has worked best for you?

Only one objective: pass a code inspection/peer review, with me as the reviewer, without me finding any bugs or having any other criticism, that has me asking you to redo something.

Notes:

• I wasn't measuring new hires' ability to finish quickly, and didn't encourage them to: I wanted people to learn how to finish well (because if it's not finished well, then it's not finished)
• People learned what I looked for in a code review: so it's a learning opportunity and a quality control measure, and not just a management objective
• My comments would have two categories:
  1. This is a bug: you must fix this before you check in
  2. As a suggestion, I would have done such-and-such
• After a while, my reviews of a person's code would stop finding any "must fix" items (at which point I wouldn't need to review their work any more).

Answer 2

Determining how to align personal development with the projects being done is a key point in this I think. Having developers analyze themselves to find weaknesses along with giving feedback on others may be a way to find what may be improved and then finding a way to measure it. For example, I may find that I rarely document completed items and so on my objectives for the year I can state that I want to improve this and that the amount of documentation I produce can be a measure of that. It may work or it may backfire depending on how I follow it really. On the one hand there may be valid concerns for this being how I improve my work and do what may be viewed as the proper way while a passive aggressive or childish view would be to produce a mountain of documentation if it isn't that good in terms of quality as that can be improved next year as this can be another point to consider: What is supposed to be the motivation to improve as much as possible all in a year compared to spacing things out?

Defining an effective developer is another element to this. Is it the person that fixes bugs best? Does new work quickest? Does new work complete with tests and documentation even though it isn't done quick? What are you calling effective since the "it depends" standard response should be clarified here.

Answer 3

Personally I try to set two sorts of objectives:

• Business-focussed objectives (this is why we are getting paid after all). For instance, "complete project X by 1 June 2009"). These objectives are often shared across several members of the team (and they are aware of this). The team can exceed the objective by bringing the project in early or by exceeding the functionality required. Individuals can exceed the objective by producing more functionality, having fewer bugs against them, or coaching and supporting other members of the team.

• Personal growth objectives, for instance completing a project involving a technology that the developer wants to add to their skill set, understanding the user's domain better, gaining leadership experience etc.

I feel that it is important that:

• Objectives are SMART
• Objectives are aligned with the needs of the business
• You do include "normal work" in objectives, in fact these are the most important objectives!
• The employee has some opportunity to exceed the objectives you set

Finally, I would stay away from software metrics as objectives - they are too easy to game and probably won't give you what you need. I would only use a metric where I want to coach someone in or out of a particular behaviour.

Answer 4

I think that having very specific goals up front, i.e., SMART (maybe we work at the same place actually), seems like a good idea in practice but it isn't very practical for most teams.

The problem really is our incremental goals change. The business changes and as developers we need to react and react properly and in a reasonable time frame.

Consider setting goals that tie with your team or group's purpose in the organization. Your team wouldn't be funded if it didn't serve a purpose - a macro purpose. Have collective goals that exist across your entire team and that align to the business. Give people responsibility and hold people accountable. Celebrate their successes and failures (if we don't fail at times we're likely not trying and that's what you want from people). HTH

Answer 5

We have a number of metrics that are collected as programmers do work, such as:

• Number of SLOC changed / added
• Number of errors / bugs injected in various stages of the process (during peer review, post peer review, post release)
• Change requests fulfilled / rejected
• Formal documents (software version descriptions, design docs, etc.)

All of these are tangibles which I find useful in presentations for management and software quality assurance. But I have never found them terribly useful in actual evaluations of people's performance - which is the point made by several of the links you listed. I've found that Joel's points here are valid - metrics never promote a good team atmosphere.

Unfortunately, we all live in a world where metrics are required by others (management, quality assurance, outside contractors, etc.). I've found that a balancing act is required - providing those metrics, but also providing evidence of intangibles - intangible being what each programmer has accomplished that is not necessarily tracked. For example, I had a programmer who spent a large amount of time investigating legacy code that no one else wanted to touch. Even though his metrics were low for that period of time, that effort was invaluable.

The only way I've found to include such things has been to push for the creation of an additional intangible category and give it equal weight with the other metrics. Usually this is sufficient to swing the balance for a particular programmer.