Stack Overflow developers: We didn't always follow coding best practices, and you don't have to either

Best practices can slow your code down. Which is why Stack Overflow's development team decided not to follow them.

programming.jpg

IMAGE: iStock/metamorworks

Best practices are there for a reason. In software engineering, they're usually designed to make code easy to maintain, as well as ensure developers don't make any mistakes that could lead to bigger issues down the line.

But that doesn't mean developers always need to stick to them. When building the codebase for Stack Overflow, for instance, engineers Roberta Arcoverde and Ryan Donovan admit that they sometimes sacrificed best practices in favor of speed and performance – and explain that following established rules to the letter aren't always the best choice for all projects. 

SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)

Arcoverde and Donovan have worked on Stack Overflow since it launched in 2009, back when the website ran on just a handful of dedicated servers. The site's small team quickly found itself having to scale-up the platform in order to meet demand, while at the same time trying to keep Stack Overflow fast and light.

"Because we went with the reliability of a full Microsoft stack—.NET, C#, and MSSQL—our costs grew with the number of instances. Each server required a new license. Our scaling strategy was to scale up, not scale out," Arcoverde and Donovan explained in a blog post.

Keeping Stack Overflow fast and lightweight remained central to the team's ambition throughout the site's history, said Arcoverde and Donovan. As such, the development team had to prioritize things like ensuring regularly-accessed data could be recalled quickly, by leveraging processes like memoization and caching.

This need for speed also informed the decisions around what programming languages were used to build Stack Overflow.

"High-level languages provide safety but have a lot more runtime overhead, so can be slower," said Arcoverde and Donovan.

"We've optimized for speed, so our code in some places looks a lot like C, because we do use a lot of the patterns that C uses, like direct access to memory, to make it fast," they said.

"We use a lot of static methods and fields as to minimize allocations whenever we have to. By minimizing allocations and making the memory footprint as slim as possible, we decrease the application stalls due to garbage collection."

But this preference for fast code came with a trade-off: namely, that it made testing and maintaining code more difficult. This is where Arcoverde and Donovan admit eschewing best practices, including what the pair call one of the "most non-controversial" – and widely accepted – good practices in the industry: automated tests.

"We don't write a lot of these because our code doesn't follow standard decoupling practices; while those principles make for easy to maintain code for a team, they add extra steps during runtime, and allocate more memory," the pair explained.

"It's not much on any given transaction, but over thousands per second, it adds up."

Similarly, Arcoverde and Donovan said they didn't write unit tests for every new feature, either. "The thing that hinders our ability to unit test is precisely the focus on static structures. Static methods and properties are global, harder to replace at runtime, and therefore, harder to 'stub" or 'mock'," they said.

"If we cannot mock a database connection, for instance, we cannot write tests that don't have access to the database. With our code base, you won't be able to easily do test-driven development or similar practices that the industry seems to love."

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)

Arcoverde and Donovan are keen to point out that they're not suggesting doing away with best practices altogether. They are, after all, there for good reason, and the pair note that Stack Overflow is in the process of trying to make its code more 'testable' now that the site has been running successfully for more than a decade.

Instead, the lesson is more around the idea that it is OK for developers to flex industry-established guidance if it helps them get the results they want from their software, not to mention cut back on the huge amount of energy developers already spend on tedious and time-consuming tasks.

As Arcoverde and Donovan put it: "The patterns and behaviors that have made it into best practices in the software engineering industry did so for a reason. They make building software easier, especially on larger teams. But they are best practices, not required practices. 

"Complex or chaotic problems require novel solutions. Sometimes you may need to intentionally break one of these rules to get the specific results that your software needs." 

Also see