In a previous post, we announced that we have opened the Transifex Engineering Manifesto to the world. In this post, we’ll go a step back and explain why we decided to invest in Quality Standards in the first place.

All of the weaknesses described below may appear when Quality Standards are absent or insufficient. A team may only face a subset of these issues, and perhaps they don’t pose such big problem. This was the case with Transifex; we had issues that sometimes affected our performance and morale, but it wasn’t that bad.

This is not a stable situation, though. As a team expands or welcomes new members, its dynamics can change significantly. The only way to avoid the following problems is to shield your codebase and product, by creating standards that safeguard the quality of your team’s work.

Bad Code

Every developer in the world that has been part of a team knows how hard and unpleasant it is to work on a codebase that is badly written. We’ve all come across huge classes you cannot wrap your head around, badly named methods that make no sense, or big parts of undocumented code.

No matter who you ask, engineers always have stories about how much time it took them to understand what a piece of code does and how to start working on fixing a bug or extending the existing functionality. These are always sad stories because this type of code really sucks the fun out of our work. It is utterly frustrating to have to deal with these issues on a regular basis, and it can really kill your morale and your performance and can make you lose interest in your work.

Badly written code has a lot of other consequences for engineers. It’s hard to debug because you can’t easily find your way through the code and make sense of it. It’s hard to test because it’s not easy to break down into distinct, testable parts. And it’s hard to maintain because any feature implementation or bug fix is much less straightforward to write. Not to mention how this can delay a project and increase its total cost significantly.

The funny thing is that, although everybody hates working on code like this, many developers do write such code. Sometimes it’s because of ignorance and lack of experience. Other times it’s because there is no process in place or no incentive to do otherwise. Or, it might be because the team culture kills every attempt individual people make on fixing the problem by themselves.

Consistency

It’s not only about bad code, however; it’s also about consistency. This is often underestimated, but it’s impressive how much time and energy can be lost due to inconsistencies.

The obvious case is when there are too many different ways of doing the same thing, all inside the same codebase or team. Formatting, tabs vs spaces, non-existing naming convention, and dozens of other examples. When dealing with inconsistency, it’s like the brain is jumping from one thing to another, doing countless small context switches; and we all know how bad context switching can be for a person’s performance.

The less obvious cases have to do with the effort we put into discussing all these differences. “Should we capitalize the first word of a commit message or not?” This question might come up from time to time in code reviews, Slack threads or water cooler discussions. It’s small but it really adds up. If you get rid of these conversations by introducing a standard, then you get to move on with your life and focus on what’s really important.

Processes

Similar to code, more or less, are processes that live around the creation of code, such as code reviews, naming of Git branches or ticket handling inside a Scrum sprint. Some teams might be lacking such processes completely, in which cases everyone does things their way.

Other teams might have poorly designed processes. If they are too weak, it leaves too much room for inconsistencies. If they are too stringent, people soon start to ignore them, as they can’t keep up with everything.

In all cases, the real issue is that there is no framework for accountability; people eventually do whatever they want and it’s really hard to have them follow a common course.

The results are the same; frustration, delays and increased costs.

Respect

Last but not least, there is an additional aspect that often gets ignored. When a fellow engineer writes code that has the issues mentioned above, it inevitably makes your life harder, because you’ll have to deal with poor quality at some point. You’ll have to make the extra effort in order to work on bad or inconsistent code, so in some sense, your colleague is not being respectful to you.

People need to feel that their time and effort is appreciated. This can be a very important factor of someone’s happiness as part of a team. Writing good, consistent code, as well as following your team’s standards means you are considerate of other people.

For Transifex this is important on its own, regardless of all the other benefits it brings.