2

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?

  • Management Skills
  • Communication Skills
  • Deliveries
  • Attitude and behavior
  • Punctuality

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?

9

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.

7

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)

  1. Completeness, Quality & Productivity of deliverables (Code, Documentation, Defect Resolution - Please note these accepted standards and values need to be communicated prior to commencement of work)
  2. Team work (How collaborative, Supportive they are when working with a team)
  3. Communication (Correct, Clear,Timely)
  4. Common Professional Etiquette (Punctual for meetings,Adherence to accepted boundaries on attendance/HR policies at organization,Respect to others)

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

  1. Completeness, Quality & Productivity of team deliverables (If possible if this can be applicable to engineers of all levels theoretically the overall completeness, quality & productivity should improve , but I haven't had the chance to see this at first hand)
  2. Contribution to competency development (Training to team, Tech Talks & etc.)

How to define measurement criteria for each highlighted area above I would leave for respective technical leadership.

1

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:

  • Frequent code reviews.
  • Ask the developer to do code review for others and look at that provided review.
  • Inspect their documentation.
  • Observe how they are enjoying work / work in team.
  • Sit down one on one frequently and ask questions about the project. How he thinks about the project. Positive/negative sides. I believe it is all individual and it is hard to rate the performance by using tools and counting check-ins. Personal approach should tell you more.
0

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:

  1. Requirement gathering.
  2. Designing solutions.
  3. Documentation.
  4. Weekly progress update calls with customers.
  5. Review junior people’s codes for best practices and company standards.
  6. Review code for good quality (As @Clair mention to identify “If developer developed a function point and committed 350 LOC to do so, perhaps after some collaborative work with a seniors could be done in just 150 LOC”).

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.

0

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:

  1. google measure performance based on self-training and educational tasks. Every developer should choose which area he/she will improve in next 6 months. And after that manager/team lead will check on one on one meeting which progress was made.
  2. Calculate contribution of each developer in improving technology process. Like CI/CD, training for a team and etc.

https://www.quora.com/How-do-tech-companies-like-Google-measure-the-performance-of-their-engineers-or-software-developers-Are-they-measured-by-their-coding-skills-productivity-feedback-from-customers-etc-What-kind-of-people-can-likely-get-promoted

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.