What is a good mechanism to evaluate software engineers' performance? We need to have a PAR session every year so would like to know how to proceed and what mechanism is used within the industry.
Should it cover following areas?
I have heard that checking SVN on a daily basis to review codes and to assess how much code has been committed by each developer is a good way. Is it fair and used within the industry?
checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry?
The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster.
HasaniK and Jakub have already identified some very valid reasons as to why it is unfair. However there are some very serious considerations to be given to the implications that can emerge as a result of introducing this as a performance related metric.
Using LOC (and in fact any other sort of linear metric e.g. bug fixing) for assessing the productivity or performance of engineers is fundamentally flawed, it essentially penalizes desired behaviors such as refactoring. If I developed a function point and committed 350 LOC to do so then I review it, perhaps after some collaborative work with a peer and discover it can be done in just 150 LOC am I going to do it? Unlikely if it’s going to impact on my perceived productivity or performance.
One of the worst examples I've ever seen in place was the use of both LOC and bug fixing as performance metrics, this essentially encouraged developers to commit reams and reams of appallingly buggy code and then fix their own bugs! Not exactly conducive to increasing velocity and quality.
In my view this approach can single-handedly be responsible for creating a culture of poor quality design, code, and documentation as engineers become increasingly focused on the committal of code rather than robust and sound design, collaboration and innovation. I've seen good teams of enthusiastic and quality engineers be converted into unenthusiastic robots dedicated solely to delivering what they consider to be the expected measure each day.
Needless to say that I left the organisation mentioned as soon as was humanly possible and since then have made it a point to ask at every single interview since then what PAR framework is in place, how can I expect my performance to be measured? If LOC is mentioned then I thank them very much for their time and if offered the post politely decline their kind offer.
I've personally found the best PAR frameworks for developers to be largely subjective, the use of 360 reviews can help to ensure that the desired behaviors e.g. communication, teamwork etc. are being adhered to and identify opportunities to improve (ensure that the 360 reviews contain feedback based on demonstrated behaviors and are not ‘complaining’). Code and documentation review are a genuine and unbiased method of measuring quality, completeness and accuracy of output.
checking SVN in a daily basis to review codes and to asses how much codes have been committed by each developer is a good way. is it fair and used in industry ?
This is definitely not a correct measurement for a PAR for Software Engineers. As Jakub has also mentioned, design takes time,sometimes there are blockers which prevent dev team from finishing a feature & making a commit (e.g. - unavailability of dev/test servers) and also in a cross functional team some members could be helping another member with their work. The list could go on..
In my opinion following list is a basic set of objectives for software engineers of any level (Junior/Senior)
In addition to above, for a senior Engineer following parameters will be more applicable as senior engineers are expected to guide at least few other junior engineers
How to define measurement criteria for each highlighted area above I would leave for respective technical leadership.
it is definitely not fair. Different tasks require different approach. You might spend more hours just designing your solution rather than implementing it.
My recommendation is:
LOC is only one simple factor to measure when it comes to evaluate performance of people who are working as Tech Lead/Team Lead or above that positions.
Because they are doing more work compare to development (code writing). For example:
When evaluating these peoples (Tech Lead/Team Lead or above positions) I think we should consider areas which @timeman789 points out.
But when it comes to developers who are set clear goals & clear tasks with the help of they are superiors I think LOC give acceptable portion to evaluate his/her performance. But I think it should not be LOC, rather whether it is Source Lines of Code (SLOC) or Effective Lines of Code (ELOC). Apart from that FP (Functional Points) also can use as counter measure to evaluate these members.
All in all I think you better to do a research and come up with different set of measures for different role of people; to evaluate performance of peoples your team or company have.
Any metric which is related to code like LOC, code quality(sonar cube), bugs, and etc is very bad. Either if you find some metric system which is working in one team it will be not working in a different team. Also, Developers always want to hack/crack performance metrics (because it will part of their work - to solve complex tasks).
From technology part I can suggest only SOLID principles - Does team really write good code which is easy to maintain(80-90% of time developers are maintain code).
Also, there is a good approach from google:
But still, this very depends on the type of task. If you are working as an outsourcer - probably you can try to find something measurable. If you working in product company with a long-life product better to measure long-time improving a whole team.
