The Irrelevant Tools Team

Software development tools teams have always been a critical part of a software development organization. The tools engineers, build and release engineers and architects help ensure that the software development infrastructure is contributing to the best and most efficient software development. But what is the extent with which a tools group can positively affect the development organization?

A Tale of Two Cities
Recently I was speaking with a tool manager who described his organization as "IT" (information technology) for the software development organization. His job was to support the development organizations essentially doing "whatever the development managers wanted him to do." It was clear that his team was handed tasks to do and his job was to manage the resources to address those needs. He clearly wasn't setting the agenda - instead he was really acting as a direct report to the development organization.

Contrast that with a similarly sized organization with a completely different tools team. The tools team there is responsible for much larger range issues - not just the installation and operational aspects of the tools infrastructure. There they play a pivotal role in defining process and architecting solutions that meet their largest quality, productivity and security goals. In this type of organization, the tools team is well recognized and funded by the engineering executive management. By centralizing these functions, they take full advantage of improvements across all the different development groups. In addition, they provide a healthy counterpoint to the software development organization - pushing for improvements that need to be made that in many other organizations, software developer's resist.

Case in Point
At Code Integrity Solutions we work with a lot of organizations to successfully institute static analysis into their organization. In the first organization, the software development managers had purchased the tool, thinking it would be a good productivity tool. They then passed ownership over the static analysis solution over to the tools team. The tools team's idea of success was to install the static analysis solution and make the URL available to the developers and to provide support for them if any problems arose. As you can guess, nobody ended up using the tool and their investment in static analysis had a negative return.

In the second organization, the purchase was made by the development managers and the tools team in order to solve their larger quality and productivity needs. There, the tools team was charged with a very different set of criteria: no new static analysis defects would be introduced for any software development. The tools team then had to figure out how to set up a deployment and process that would meet that goal. This necessitated changes to each developer's process, reports to measure progress to multiple parties and the creation of a robust infrastructure that changed the way they developed software.

The Search for Relevance
In recounting these situations, I'm reminded of all the experiences and literature I've read about IT organizations in large corporations. IT, when considered as just the folks who operate the helpdesk, distribute your username/passwords and come over to fix your machine when it breaks down, is a support infrastructure that is nonstrategic and a target for outsourcing to whoever can provide it the cheapest. IT organizations who search for ways to create significant efficiencies or enable new business models are the treasured goal of any CIO or VP of IT.

Tools teams are not that much different in this respect. When tools teams make the business of developing software better, faster and cheaper, they have a seat at the table, playing a strategic role in making product development organizations more competitive. Which organization type do you think brings more value?