At this year's SD West Conference, I was surprised by the number of companies (most of them new) focused on Build tools or tools with added Build functionality: Products like AutomatedQA's Automated Build Studio and Urbancode's AnthillPro3 Build Management Server and Build functionalities built into Nokia's Carbide.C++ environment. Today's Build tools are a far cry from make. Build is, against all logic, sexy.
So what's driving this increased interest in Build tools and the plethora of new products in a corner of software development that one might reasonably characterize as rather unglamorous? After all, we're just talking about the process of turning a bunch of interdependent chunks of already-written code into an application, an activity to which, when you're intently focused on actually writing the code, you'd probably like to devote as little thought—and as little time—as possible.
I asked that question of some experts in the field and did some research of my own, and the conclusion I was driven to is simply that it's Build's turn. There is not one reason for the current Build buzz, but several interrelated reasons, having to do with complexity, distributed development, diversity of development approaches, and compliance. And these forces are resulting in some powerful new prescriptions for easing the pain of the Build process.
Complexity
Anything you build on a large scale or with intense passion invites chaos.
—Francis Ford Coppola
Life happens too fast for you ever to think about it.
—Kurt Vonnegut
The growing complexity of software obviously creates a need for better development tools, and that includes Build tools. "Applications keep getting larger and larger," says John Ousterhout, the creator of Tcl and founder of Electric Cloud, a software production-management company, "with the result that Builds take longer and longer." He points particularly to the embedded device space, where Moore's Law increases in chip memory make possible larger and larger applications.
Factor in multiple variants of the software for different chip sets, and the Build process turns into a major time sink. "At one point," Ousterhout says, "LSI Logic had a software package that took two-and-a-half hours to build each variant, and they had to build about 30 variants." Slightly over three days for a full Build. Ouch.
But complexity impacts all aspects of software development; why so much focus on Build tools in particular?
Apparently, it's because it's Build's turn. Ousterhout sees Build and test tools as offering the greatest opportunity for improvement right now precisely because Build and other backend tasks have been largely ignored by commercial software companies until recently. Electric Cloud uses the term "software production" to refer to backend tasks such as Build, package, test, and deploy; the analogy is with movie production tasks that occur after the frontend activities create the raw footage. The frontend tasks in software development, like code editing, debugging, and source-code-control, have had the attention since the '80s and the major gains have been made there already. But the backend processes "are ripe for improvement." There is simply more room for gains to be made.
That's one factor.
