How Engineering Managers Can Optimize a Large Codebase
Marc Andreessen famously declared in a 2011 Wall Street Journal article that software is eating the world. Not only did this statement inspire entrepreneurs to launch countless startups, it also showed larger enterprise organizations that it was time to embrace a technology-driven landscape. In an article for The Atlantic, James Somers wrote, “More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code.”
In that same article, Somers also highlighted an incident in which a software platform caused a widespread 911 outage. The cause was a line of legacy code in which programmers set a threshold for how the total number of calls that the system would process—and in April of 2014, the counter exceeded that number.
This creates a new challenge for engineering managers. As companies continue to grow their engineering teams, what does this mean for your codebase project management, especially as it becomes more complex each year? Here are a few suggestions to help keep your codebase under control.
Give New Hires Plenty of Time to Adjust
Developers want to do meaningful work as quickly as possible. Often, this eagerness is a quality that engineering managers look for during the hiring process. But after you find and hire those programmers, one of the keys to codebase project management is giving your newest programmers time to onboard properly.
Jon Chan, a Developer here at Stack Overflow, wrote an extensive blog post about his first six weeks at the company. In his first two weeks, he learned the team’s tech stack. In his third and fourth week, Chan dissected how the group organized its codebase. “I felt pretty comfortable in the technologies in their ‘platonic’ form, but I still didn’t understand how everything was organized in Stack’s actual codebase and configuration,” he wrote. “Learning C# and .NET was just the beginning. Figuring out how it was done to make Stack Overflow what it is…that’s s a completely different adventure.”
Like many of his colleagues, Chan was an accomplished developer before he joined the team. But this shows that even the most talented programmers will need time to get acclimated to your codebase. If you rush this process, they could add to your rapidly growing codebase, but in ways that negatively affect your products.
Break Your Engineering Team Into Specialized Functions
Adam Pisoni recently sat down with First Round Review to discuss how he helped grow Yammer from a team of five to a company of 500 employees. When the group was smaller, he and his programmers worked on the codebase together. But as they started to grow, so did the codebase—and not in a positive way.
The solution to improving their codebase project management turned out to be reasonably straightforward. Yammer decided to break its engineering team into smaller functions, which enabled the company to distribute work more efficiently. “The way in which we organized changed the shape of our technology,” Pisoni told the magazine.
Pisoni also says that when he was an individual contributor, there was no emphasis on process and nothing resembling version control. Today, he says that would be absolute insanity. “Now we know that the only way to have a large group of engineers work together is to have a development methodology,” he continues. “But still too few companies lack an organizational methodology that helps your company operate effectively without requiring you manually managing everything that happens.”
Looking for a better process for managing your codebase? Find out how Stack Overflow for Teams can help.