How are software engineers objectively measured when problems span such large difficulty ranges and there are multiple ways to implement solutions?

Question

Always been curious how “workload” is assigned and estimated for software engineers.

In: 92

Answer 1

There’s no good way to do it, that people have figured out yet.

You can try to measure output in terms of some countable metrics, but these all have problems:

1. **Lines of Code** seems like something you could measure, but software *quality* isn’t the same thing as software *quantity.* In fact, there’s research to say that the number of bugs in code is directly proportional to the amount of lines of code, so if you use an unnecessarily large amount of code to solve a problem, you’re probably making things worse. As a general rule **Complexity must be justified*****.*** Writing more code than you need to, because you get punished if you don’t, is bad management and technical malfeasance.
2. **Number of Commits/Number of Completed Tickets**. Some work items are very complicated and require a lot more time. A person who only takes small, easy tickets and completes a lot of them is probably not as valuable to an organization as a person who takes the large, complicated tickets and completes those. In fact you might expect that the more experienced and higher-paid programmers probably focus on the later exclusively.
3. **Defects/Regressions.** In other words, is the person breaking things along the way? Are they creating more problems than they solve. A person who seems to get a large volume of work done (see #1 or #2) but they work they produce has lots of problems that require fixes/redeployments/rewriting/hotfixes/etc is probably more hinderance than help. But then again, as systems get larger and more complicated, it gets a lot harder and harder to change one thing without inadvertently causing changes somewhere else. Especially when there is time pressure.

A lot of it is unfortunately subjective. Does it feel to you like the programmer is dependable, reliable, efficient, proficient and competent? Does the work they produce meet the needs of the organization? My suggestion is that you sort of keep yourself aware of what’s going on (without watching over the shoulder, or micro-managing, of course) so that you can make these kinds of subjective judgement calls.