Always been curious how “workload” is assigned and estimated for software engineers.
In: 92
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.
Latest Answers