Questions around standardization often arise when an Engineering team grows. What kind of code style rules should we follow? What type of language should we use? What tools, frameworks, and libraries do we use?
This article delves into standardization in software engineering teams and highlights its pros and cons. While standardization can bring advantages like consistency, quality, and efficiency, it can also have negative impacts like limiting creativity, causing inefficiencies, and decreasing motivation. Additionally, standardization can limit flexibility, increase the risk of errors, and affect developer retention.
What are the benefits of standardization?
Consistency
All your engineers build things the same way! This eliminates potential bottlenecks; someone else can take over with minimal overhead if someone falls sick. Going from project to project is easy!
Quality
Once you have chosen the best tools for the job and learned the best ways to use them, you see a boost in quality. You can easily avoid making the same mistakes in a new project using the knowledge you’ve gained from previous projects.
Efficiency
This is a combination of the two previous points — when how people work is agreed upon, the focus becomes on what is being worked on. Instead of worrying about what library is being used, you can focus more on the project’s business requirements. And with better quality, you spend less time on bugs!
Onboarding new people
If your standards are correctly documented, it is much easier for new people to join the team; they become effective team members much sooner.
This sounds amazing! But is there a catch?
Standardization also has a few drawbacks, less evident than the benefits!
Limited creativity
You might lose innovation if you have established rules for building things! An Engineer might have unique ideas and approaches that bring value to the department, but they get dismissed or overlooked in favor of standardization.
Inefficiency
Different projects have different requirements — and if they are all handled by the same set of rules, you create inefficiencies. For example, if you’ve agreed to use node as a language in your company but have a new service that does CPU-intensive work, then the agreed-upon tool will produce a subpar result.
Decreased motivation
Engineers may become less motivated or engaged in their work if they cannot make their own decisions or use their preferred tools and processes. This can lead to decreased productivity and quality of work.
Limited flexibility
Change is inevitable. Your company might move in a completely new direction requiring a standards change. Instead of being able to deliver value, you have to spend time adapting to standards that do not fit your project or take on the extra work of changing them. Changing standards is extremely hard as they require you to change the minds of everyone involved. Standards also affect everything your team has built thus far, so a change might cause issues with the work that has already been finished.
Higher risk of errors
Although standards reduce the risk of various bugs, a bug in a standard process or tool propagates to every project you’ve built!
It affects developer retention.
We’ve all grown tired of something and want a change at one point. If all your teams work the same way, motivating a team member to try a different team instead of trying another job is hard.
So what should I do?
I recommend having different standards levels; some are department-level standards that all teams must follow, while some are team-level standards that only the team should follow.
Department-level standards should be more universal, e.g., where you host and deploy your code, while team-level standards should be more specific, e.g., what framework you use.
This allows you to have most of the benefits standardization brings while also addressing the downsides!
Top comments (0)