Trends in the programming world tend to be heavily driven by large corporations. This is especially true in today’s world of open source projects, where new releases from large tech companies often receive a hero’s welcome before anyone outside the sponsoring organization has had enough experience with the project to objectively evaluate it. The coverage corporate-backed projects will typically continue as developers begin to apply them to their own code, with mentions appearing regularly on technology and programmer news sites, blogs, and social media.
The level of fanfare around corporate-backed projects can create the impression that “everyone is using” a certain technology, tool, or technique.
Lost in this coverage and the excitement that is automatically assigned to code released by big brands are the nuances of the specific problems a project is intended to address. Without a thorough understanding of the scenario a particular solution was designed to solve, it is difficult to accurately gauge that same solution’s suitability to other (potentially very different) problems.
Before adopting any technology, be sure that you can answer the following questions:
- What specific problems does the proposed technology solve?
- Are those the same problems you need to solve?
- Do those problems exist at the same scale?
Facebook, Google, Microsoft, et al. operate on a massive scale, one so large that it presents fundamentally different challenges than those encountered by most other companies and projects. In particular, they manage thousands of software developers who build software used by hundreds of millions of users every day. This leads to solutions that are designed to mitigate some of the challenges that arise from having so many people working together on software that handles such a staggering amount of traffic.
Most teams, even those at successful and profitable companies, operate on a scale that is much smaller and does not exhibit the same kind of problems. Your team probably has far fewer people on it, and you probably don’t have one quarter of the world’s population using your software. From this perspective, it is somewhat surprising to see a release from one of the large technology companies being immediately considered for use on projects that operate at a scale that is 1000x smaller, whether that scale refers to the number of developers, lines of code, or number of users of the system.
In many cases, it is prudent to subject popular tools, technologies, and techniques to additional scrutiny in an attempt to counter-act the inherent bias we all have for the new, the shiny, and the popular. Will there be times that a tool from one of the big tech companies will be incredibly useful to a project you are working on? Almost certainly. But this does not mean that adopting such tools should be met with less scrutiny due to the reputation of the sponsoring organization. Instead of assuming that use of software with a connection to a successful company is in some way correlated to that company’s success, try to ignore the source of the code and examine its objective benefits and risks.