Engineering tools as means for collaboration and productivity

Many senior managers don’t understand the importance engineering tools have in facilitating collaboration between developers and between teams, and they consider the day-to-day processes—the programming languages used, the testing environments, the validation system—just minor issues that need neither investment nor planning, due to the huge range of tools available on the market and to the variety of internal processes that each team creates to execute their own projects. 

It is a mistake to downplay the importance of these concepts. Tool standardization has the potential to bring huge productivity gains to the company. Sharing repositories, nurturing a culture of testing and code review, and integrating guidelines into tools enable engineers to produce the platforms that will make the company stand out over the competition and allow them to be efficient and innovative.

Defining engineering tools

Engineering tools are the software engineers work with daily. Developers spend their lives writing, compiling, and testing code. When they are satisfied with the tests, they submit both the code they have written and the tests to be reviewed, ideally by technically experienced engineers. The reviewer can and should make comments and ask for changes, and when everything is right and approved, the code goes onto a conveyor belt, or CI/CD (continuous integration, continuous delivery), which is a mechanism for automatic validations of that code, checking, for example, security loopholes, or that the formatting is done correctly. 

After going through this validation environment, the code goes into production, i.e., it enters the repository—before that, it was only on the developer’s machine—and is integrated into it. This process directly affects developer productivity and can be slow depending on the amount of automation and bureaucracy involved. The goal is for most internal processes to be automated, and one of the points that has the most impact on this is the repository—whether it’s one for the whole company, one per team, or one per group or sub-group. What happens when these repositories are scattered around the company, in large numbers and in a disorganized way, is that there is no easy way to visualize them, and the code they store. 

Information at hand

One aspect that shaped Google’s work culture almost from the start, for instance, was its investment in engineering tools. These tools were built to make life easier for developers, who had at their fingertips everything they needed to write, test, and deploy new code into production. There was no need for many processes between people because the tools themselves simplified actions. No one wasted time thinking about how to perform tasks in the engineering lifecycle.

The engineering tools were so standardized that there was only one way to put the code into production, and this approach dictated the collaboration strategy. One of the main elements of this system was the existence of a common repository that brought together all the company’s code. What’s more: it was indexed. Every time someone wrote code, it became searchable by keywords. Programming languages were also standardized, and, in the beginning basically only two programming languages were used by the whole company. Libraries became more and more complete as new solutions were incorporated, leaving developers free to concentrate on business differentiation. (It’s important to remember that Google’s tools solution is not replicable because it was conceived and built in a different era, when cloud services didn’t exist.)

The goal is for most internal processes to be automated, and one of the points that has the most impact on this is the repository—whether it’s one for the whole company, one per team, or one per group or sub-group.

There are many reasons why there is an overabundance of repositories in organizations. This is how the situation usually unfolds: the company is making, say, a credit card processing system, and the developer creates a repository for the system’s code. As it grows, a new director is hired to run the banking system. This person thinks that the system will never use anything from the existing credit card processing system, and creates another repository, building a completely independent system. 

A company can have numerous repositories like this, which is often explained by the need for speedy solutions. The smaller the repository, the faster the tools work. If the process is getting bogged down, the developer feels an impulse to create a new, separate repository, without integrating it with the rest of the codebase. You may even have several repositories, but if you want developers to collaborate and reuse code, there needs to be a search tool that works as if there were only one.

When the code is shared by various groups in the company, there are directories, and each one of them has a file with the name of the owners of the code in that directory, the key people who need to authorize any modifications to it. The tools that work well and provide productivity gains are integrated so that you can search (directories are huge, as there are millions and millions of lines of code in a company) across the directories to find what you want. 

Third-party tools

Today’s engineering tools don’t have to be created in-house, but it is important to choose them well and use them consistently. There are many options for:

• Programming languages
• Development environments
• Testing environments
• Code review systems
• Systems for putting code into production Systems for automatic validations

For all of these, there are a variety of tools, often provided as pre-assembled packages. Technology leadership must be very intentional in how it uses these services, which need to be chosen rationally and standardized across the various areas of the company. 

Other companies, such as Meta, have followed Google’s lead in standardizing their tools and using a single repository for the entire company. In Brazil, an example of this is Nubank, which has taken standardization very seriously since its inception, going to the extreme at some point of using only one programming language for the entire company, which has its pros and cons. 

Easy-to-read code

Developers spend more time reading code than writing it, which is why the organization of code affects the productivity of any company. A smaller number of languages and the standardization of formats help professionals to quickly understand what they are reading, know whether they need to make changes, and find problems. Rather than imposing guidelines determining how code should be written, ideally, the tools adopted by the company would automatically ensure this standardization.

There are huge arguments about where to put the parentheses in a code, whether the content of the parentheses goes on the same line, what to put on the next line, and whether each line should have a maximum of 80 characters because that’s the right length for printing, or whether it’s all irrelevant. When a company has a single integrated tool for everyone, formatting can be done automatically, no matter how the person has typed. No one needs to spend energy checking if the code is formatted correctly or culturally reinforcing these guidelines, because they are simply automatic. Developers’ eyes get much better focused on reading efficiently when formatting is consistent across the company. This is very important at critical moments, such as when an incident occurs. 

A basic concept in programming is that everything you do with one language can be done with any other.  No programming language allows you to create more possibilities, in the same way as in human language: everything you can produce in English, be it prose, poetry, or a social media post, can also be done in French or Greek. It’s the same for computer languages because Python doesn’t do anything that Java can’t do. Even if the result is the same, however, there are advantages to standardizing and limiting the number of programming languages used in an organization.

No programming language allows you to create more possibilities, in the same way as in human language: everything you can produce in English, be it prose, poetry, or a social media post, can also be done in French or Greek.

Communality

In addition to the multiplicity of repositories and outsourced services, it’s common to find companies utilizing a Tower of Babel of programming languages, sometimes with more than 20 of them in use, because of the disorderly growth of technology and the lack of direction. 

Developers’ instinct is to design customized processes suiting their personal preferences. The situation gets even worse when the company has departments that don’t communicate well with each other and work siloed, each tackling projects in their own way, with no idea of how the engineering staff in another department is dealing with similar problems. Often, there is no one dictating how the tools should be used, or which languages are preferred.

The best world is when a company starts off already on the right path, as was the case with Google because this prevents future technical debt and provides a perpetual advantage. When this doesn’t happen, the sooner an intervention is made to focus on tools and increase standardization, the better, because as the company grows and languages and third-party services proliferate, any attempt to change things later will seem imposing and limiting for developers. The tendency is for each developer to continue working in the language and tools they like best and try to preserve the code they have already written. 

Using common tools and software allows teams to be interdependent and to work together, which is positive for the company. Sometimes, collaboration must be somewhat imposed because the functionalities that need to be produced for the business are more complex than what each employee could achieve working alone. One way to encourage exchanges is to use code as collaboration. Clear code, with common languages and standards, increases the ability of teams to understand each other.

With fewer programming languages, engineers become more fungible within the organization, because it’s easier to move from one team to another. If each team decides to write code differently and someone changes teams, newcomers must spend their time learning the new tools and standards, and it will take them longer to become productive there. If a project gets delayed, key people from other teams can step in and solve the problem. Without standardized tools, all this collaboration is hampered, because whoever is going to help must first learn the standards from scratch.

The gain in agility is even more crucial in critical situations, such as when an incident occurs or when an emergency task force is formed for a priority project. In these situations, every minute that passes without a solution can mean huge losses, and the possibility of the problem being found and resolved faster is much greater if the company’s most senior individual contributors are called in and know the code well enough to contribute.