The Developer Tool Revolution

“DevOps” is perhaps one of the worst buzzwords in the computing world today in terms of sheer confusion. It can be exceedingly difficult to track down an actual definition of DevOps, and this has led many to dismiss it as meaningless hype; however, DevOps has demonstrated remarkable staying power in spite of its nebulous conceptual nature.

Before we get into the focus of this article – that is, the power that developer tools have to help transform the way software is created and released – let’s take a look at this transformation already well underway in the software industry, and see if we can’t clear up some misconceptions.

DevOps is a contraction of “development” and “operations” – referring to software development and IT operations. While software development is pretty self-explanatory, you may or may not be familiar with what constitutes IT operations. Operations teams, traditionally, are responsible forpretty much everything tech-related that the developers aren’t. In simple terms, they make sure everything stays running – managing things like servers, storage, and network infrastructure. If something goes down, it’s generally not up to the developers to fix it – it’s up to IT operations management. Now, in the past, the development and operations teams within a given company have functioned for the most part independently – once the product is out there, development is done, and it’s up to operations. This is where DevOps has aimed to change the industry. It begins to blur the borders of development and operations, bringing the teams together into a much closer relationship. Gone are the days when devs create a product and ops manage it after release. These days, operations specialists are involved with the development process from the outset of planning, and developers help to maintain products and services throughout a continuous release strategy.

The origins of DevOps lie in the practice of “agile software development”. Codified in 2001 in the Manifesto for Agile Software Development (aka the Agile Manifesto), this is, above all else, a shift in the philosophy of the software development process. Traditionally, development followed what’s known as a “waterfall” approach: first, assess needs and plan out the software; next, design & build a large release, containing hundreds of new features; finally, test everything, make sure it works, and deploy. There are significant problems with this approach – a major one being that, when a project begins to run out of time, what’s left is generally the testing phase; testing is generally not what you want to cut short. In addition, in the brave new world of SaaS (Software as a Service), poorly tested releases coming out months apart are simply no longer feasible. If Facebook encounters a problem with, say, its “like” button, or its sharing functionality, users can’t be expected to wait until the next major release for a fix. Because of this, operations teams monitoring the service as it’s running must be able at a moment’s to notify the dev team of any problems, and a fix must be able to be released immediately. The Agile emphasis on testing automation ensures that each feature is up to spec, and therefore ready to be deployed, as soon as it’s completed.

So, essentially, DevOps is a culture of increased collaboration between development and operations. However, part of what leads to confusion when discussing the term is the way it’s frequently used today – instead of referring to a holistic cultural shift within a company, it tends to mean that the company uses tools built to facilitate a DevOps environment: communication tools, automation tools, monitoring tools, etc. These tools are, indeed, the primary fuel of the DevOps “revolution”; however, while it’s common practice to refer to these as “DevOps tools”, this is a little misleading. In reality, there are no “DevOps tools”;there are tools developers can use in the implementation of a DevOps culture, but these are still developer tools. “Developer tools” refers to “any program or application that helps developers devise, debug, test, or in any other way support code” – and these are the things truly at the core of the software industry’s current and upcoming transformations.

The developer tools market has been expanding incredibly quickly, and with good reason – this is where the innovation lies in the software industry. These are pieces of software designed to aid in the production of software. While software has become ubiquitous and incredibly complex, the tools used in its production have for the most part been of remarkably low quality, quickly hacked together for whatever problem is being addressed. The very process by which software is produced is changing, and more and more workplaces are being transformed every day – all this thanks to new software coming out almost constantly, addressing systematically a wide range of software development problems. These tools aim to aid developers (and operations specialists) with every step along the development process. There are applications like DataDog that make it easier for developers and operations specialists to monitor their systems; like Jira, which helps teams plan and track projects & issues; like Slack and HipChat, which help keep everyone in communication with everyone else; like Docker, which automates the packaging of software into containers; the list goes on. Jira was released in 2002 as the flagship product of Atlassian, a company specializing in developer tools; these days, they produce a wide variety of tools, including HipChat and Bitbucket (an alternative to GitHub) – and have now grown large enough to acquire tools from other, smaller companies, like Trello (acquired in January 2017). Originally a small startup funded on credit card debt, Atlassian is today a giant in the tech industry – this shows the incredible potential that developer tools hold.

Developer tools are proving to be solid investments, too. Take, for example, the recent acquisition of developer platform Fabric by Google. Fabric was developed by Twitter, but plenty of independent developer tool companies are doing just fine – sometimes even better. Just look at Twilio, a service that allows developers to abstract the telecommunications process, and operate telephone services programmatically. The company was started by developers addressing real problems that they themselves encountered, was funded on venture capital, and is now large enough to be traded on the NYSE – and, like Atlassian, to be acquiring developer tools from smaller companies. Their success, and that of companies like them, can be partially attributed to the focus placed on the developer. In this space, the primary market is the developer, not the enterprise – and developers respond to authenticity. The focus on user experience that developer-run companies often provide can prove especially competitive, even against tech giants and their extensive infrastructure. Acquisitions of smaller companies by places like Google, Oracle, and IBM, as opposed to the development of in-house competition, show the value of this mindset.

As another example, take one of our recent investments: developer tool startup Split.io. Split, too, was started by developers set on solving real-life problems. Split is a tool for automating targeted rollouts – this means that developers or operations specialists can easily and continuously release new features to targeted groups. The DevOps and Agile worlds place large emphasis on continuous deployment (CD) of software – releasing new builds of software after the completion of each feature, as opposed to large fixed releases. Split describes itself as post-CD, with good reason. Features are still continuously deployed; however, Split provides its operators with the ability to target arbitrarily specific groups of users for specific feature releases. In addition to easy beta testing, this allows companies to easily provide different versions of a feature to different groups of customers. Perhaps even more useful is its ability to immediately kill any released feature. The remarkable feature of Split is that all of this is accomplished without ever touching the code, aside from an initial SDK injection. This makes it harder to break anything, and makes it possible for non-developers to both control the release schedule and mitigate any damages with ease. Split now has the chance to grow and help millions of companies and development teams smooth their process and provide better service to customers.

By making the development process simpler, and removing a lot of the annoying and confusing grunt work that has traditionally come with coding, developer tools are helping to open the door for a much larger segment of the population to begin developing software. Another of our investments, Sourcegraph, gives users the full power of an Integrated Development Environment (IDE) right in their browsers. IDEs help to reduce human error in coding by automating a large portion of code review and syntax generation. The proliferation of developer tools like Sourcegraph, Split, and their kin is roughly comparable to the Industrial Revolution, in terms of shifts in production – instead of each part being painstakingly produced by hand, automation and standardization can enhance and speed up the production process, bringing the fruits of producers’ labor to a wider audience and exponentially increasing the number of producers themselves.

With the power of these new services and infrastructures, and cultural paradigm shifts along the lines of DevOps and Agile methodologies (fueled in large part by the proliferation of developer tools), the industry may look entirely different in 10 years time. Or it may not. It can be difficult to separate hype from reality. Regardless, however, developer tools are and have been making a big difference in the way software is produced and deployed, achieving widespread use while reducing human workload and mitigating risk. From any perspective, this is a solid and vital section of the industry.