The Evolution of C Code Quality at Bloomberg

When I was at Bloomberg around 10 years ago, the code quality was good but not the best. Our team sacrificed quality and testing for speed in order to deliver our projects on time. However, as time has passed, things may have improved.

Background

One of the roles I had at Bloomberg was the designer and author of the Ticketing API, a C interface for the TOMS and POMS legacy code. We were meticulous in ensuring that the best practices of the time were followed. This included a significant amount of resistance against odd ideas from John Lakos, who was more focused on proving that the STL (Standard Template Library) was logically flawed due to the way allocators changed the type of a container.

Leveraging Best Practices

Back then, we made efforts to adhere to best practices, including rigorous testing and code reviews. For instance, we pushed back against Lakos' views, but it was challenging to maintain consistency given the diverse team and differing opinions. However, this rigorous approach helped us create a robust and maintainable codebase.

Legacy Code and Forking Challenges

The application at Bloomberg faced unique challenges due to the large amount of legacy Fortran code. Forking was a common practice, but it created interesting virtual address alignment issues. For example, the BSS (Block Started with Symbol) and other static code segments shared the same virtual addresses. This was a clever trick, but it posed significant deployment and scaling challenges.

We attempted to use shared libraries, but discovered that they couldn't be forked with the same virtual addresses, leading to unexpected behavior. This was a major drawback, as shared libraries are generally more efficient and easier to manage. The experience taught us a valuable lesson about the limitations of certain practices in a legacy environment.

Boost and Infrastructure

Boost libraries were forbidden at Bloomberg, but there was an exception: if someone cut and pasted the Boost libraries into their own source code, it was acceptable. This made it appear as though the libraries came from the infrastructure group. In reality, this approach defeated the purpose of using a standardized library. I believe we gained a lot of insight by diving into this issue.

Moving Forward

Since my departure, I've heard that Bloomberg has matured in several areas. One notable change is that they no longer attempt to build their own versions of the standard library. Instead, they leverage widely adopted and tested libraries to ensure consistency and reliability.

Overall, my time at Bloomberg taught me a lot about the complexities of managing legacy code and the importance of adhering to best practices, even when it means slowing down the development process. As a seasoned developer, I believe that while Bloomberg faced some unique challenges, the lessons learned from those experiences remain valuable for both the company and the broader development community.

Conclusion

Bloomberg has a rich history of developing large and complex systems, and while the code quality was good but not the best, the team continuously evolved and improved its practices. The experiences gained during my tenure serve as a reminder of the importance of best practices and the challenges of maintaining large codebases over time.