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


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

In: 92

That’s a problem no one has really solved yet.
The way it usually works is that you break down big tasks in more manageable sub-tasks. Then you estimate how long each sub task is going to take, based on how long similiar sub-task took in the past, add up all the sub-tasks, then add some allowance for tasks taking longer than estimated, then add some more, and finally you have a number that you can tell your manager.

If you have a team of people you generally know who works faster or slower and assign them a corresponding amount of work.

With a bit of experience it works reasonably well.

Nobody is objectively measured.

The concept of “objectively” measuring somebody’s contributions in the workplace was created in response to blatant unfairness and inequality. As managers and workers struggled with opacity in pay and increasingly large compensation packages for executives, many people demanded answers and clarity for evaluating performance and progress for raises and promotions.

Sure sometimes the metrics can make a lot of sense, especially in more concrete task-oriented work, but mostly this still serves the interests of capitalists and the ultra wealthy by reinforcing the idea that people shouldn’t be equal and providing a convenient pretense for paying executives exhorbitant amounts because of “performance metrics.”

This isn’t to say that no metrics should be used for gathering feedback and encouraging progress through promotions and raises. It’s just to say that they are mostly made-up and should not be considered complete nor infallible. Push back. Ask questions. Share information among co-workers. Unionize. Question executives and wealthy shareholders’ interests.

I am a software engineer and certified SCRUM master.

The answer is very poorly.
The trick is to spread out the bad estimates so the badness cancels out and on average you get something approaching accurate.

The SCRUM alliance recommends having the engineers each give an estimate of how many “points” a task will take. Then taking an average. So probably you’ll get some rough consensus on how many points a task will take.

How long do you take to do a point? Nobody knows, this will change from team to team, that’s literally the reason we’re calling them points rather than something like days or hours.

So at the end of a certain amount of time, we count the total points of all the tasks done.
This gives a rough estimate of how much stuff the team can do in the period of time (a sprint).

So what if the whole team put really big or really small number on their points? This will mean that they’ll also do a huge/tiny number of points per sprint, so you’ll know how much they’ll do the next time.

What if they’re real good at some stuff, but bad at others and they give them the same points? Well them being wrong in both places will cancel each other out. Ditto with the team members being real good/real bad at their jobs.

Of course literally nobody does it right, but it’s fun to dream about what could be.

It’s a combination of experience and guessing. If you or other developers already did similar tasks or know exactly how to implement a task you might get a good estimate. If you’re doing something completely new, you just guess. Make the tasks small enough to handle and usually the good and the bad estimates add to a good average that works.

Frankly the estimate is one my least favourite parts of a project especially when the customer wants a delivery date and the total costs in advance.

Keep in mind that there’s a million different ways to “measure” software engineer productivity and estimates and it’s constantly evolving. To keep things simpler I’ll focus on modern SDLC (software development life cycle) processes that many teams use these days (You might hear the term agile a lot).

Generally speaking, larger problems get broken up into smaller ones. A lot of teams will try to break up the problem to a point where individual tasks ideally take only 1 or 2 days to complete. Obviously there will be larger ones but a good team will do everything they can to ensure that no particular task ever takes more than a week or two to complete. The smaller and more specific the tasks are, the more likely you will be able to accurately guess how much time it’ll take for someone to complete.

Most teams will try and collaboratively gauge the complexity of the task. They look for things like risks. For example, does the task need someone with specific experience or knowledge? Is it possible that another team can prevent you from completing the task? Is it something that your team has never done before? Does testing the task require a lot more coordination? If so, pad the initial estimate until your team feels relatively confident that they can do it in the estimated time. The team will try and build a consensus that everyone on the team would be comfortable with and discuss outliers from the team to understand everyone’s though process and concerns.

As for how the team decides on implementing a solution, most of the time you have an experienced engineer lead a design session with the other devs. In these sessions they plan out how they will solve a task or a set of tasks and makes sure everyone is comfortable and understands what it is they’re building. If the project is large enough you might have someone more senior (architects) working with multiple team leads to lay out the larger picture that they will then take back to their teams to figure out the details.

If you’re really interested in it you can read about modern SDLC processes, there are literal textbooks written about it. Modern processes fall under the “agile” philosophy but there are tons of ways of actually doing it. You can take a look at things like SCRUM and Kanban to get a feel of how some of these work from a project management standpoint. But from an engineer standpoint, nearly all modern agile processes follow the spirit of what I described, even if the specifics vary based on the team. I’m being vague here because good teams will be flexible and adapt the process to fit their situation, skills, and needs. Which means the specific process any given development team follows will be different from others, even if they’re in the same company or have the same leaders.