No matter what software development process you follow, there always comes a point where you need tools to support that process. Most of the time, these tools serve the purpose of providing information inputs for your development teams, and these inputs are generally of two types: project tracking information, or operational information. In the former category you have tools like JIRA or Pivotal Tracker, while in the latter category you would find products like Splunk or SumoLogic that let you analyze logs or other data center information.
In small startups, where everyone involved with a project probably sits within ten feet of each other, there is generally a casual attitude toward managing information inputs, since it's easy enough to get project updates by walking over to someone's desk, and operational commitments are limited. Eventually, though, as a company scales, it needs tools to provide insight into its development process and day-to-day operations, at which point the question becomes: build or buy?
There are good reasons to roll your own tools: it's inexpensive at the outset, and what you need might be much simpler than what's offered in a commercial product. There can also be intellectual benefits to building your own systems, because you can potentially gain insight into your processes and operations when you have to find ways to glean information from them, to say nothing of the addition to general development knowledge and skills. Google, for example, is famous for their "Google on Google" philosophy, where all the systems used by the company are either built in-house or are highly modified open source solutions. The belief is that the knowledge gained from having to build, maintain, and use these systems will translate into new and improved Google products.
The initial low financial cost, however, eventually leads to very high support costs. Whoever built the system becomes responsible for its ongoing care and feeding, even if that's not their primary job, and woe to you should that person leave your company. Google has the advantage of being able to afford to maintain dedicated engineering teams for their tools, but for a start up company, this would mean adding yet one more responsibility for a likely already overloaded team member.
When I joined Sauce Labs, almost all the tools in use were homebrewed, with the exception of JIRA for bug tracking, and had been developed in early days of the company. They reflected not only a completely different development process - JIRA tickets were categorized by product area instead of Scrum team, for example, so there was no clear responsibility for them - but also a vastly different concept of what the company was, from an operational perspective. Before we could even think about moving to Scrum and DevOps, we had to consider what tools we needed to support the transition.
At this point, the question of build v. buy had a clear answer - we didn't have the resources, in terms of time or personnel, to build new tools or re-build the ones that existed. We undertook a drastic overhaul of JIRA to reflect the way we wanted to use it, and invested in SumoLogic as our platform for operational information. We installed giant monitors throughout the DevOps portion of our offices so everyone could see how our operations were tracking, and these provide us with the real-time information we need to make agile decisions and identify issues as they start to happen, instead of after they have caused problems for us and our customers.
Every crafter needs tools to produce their works, but just because they have the unique ability to make their own tools doesn't mean they should. Instead, as with the rest of agile practices, they should look at their strengths and weaknesses, their knowledge of what they can accomplish, and decide on whether to build or buy based on what will enable them to focus on and produce the masterpiece that is their ultimate goal. This question of build vs buy comes up with our customers at Sauce Labs quite often. Many customers think about building their own Selenium or Appium grid, and some even decide to do it. The majority of them, however, come back to Sauce Labs when they realize the massive effort it takes to maintain the infrastructure and the constant updates to browsers and operating systems. This busy work does not add to their strategic mission. In fact, it takes them away from their ultimate goal of building an amazing web or mobile application that performs as expected every time, for every user, on every platform and operating system.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the tenth post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Start at the beginning and read the first post here, or read the next installment in the series.