Developers Are The New Conductors

Guest author Matthew Baier is the COO of Built.io.

There’s a scene in the new Steve Jobs movie where Apple cofounder Steve Wozniak, the engineering genius who worked on the hardware and software of Apple’s earliest computers, confronts Jobs and asks, “What do you do?”

“Musicians play their instruments,” Aaron Sorkin’s fictionalized Jobs answers, comparing himself to a conductor. “I play the orchestra.”

Of all the flaws in Sorkin’s movie, this may be the biggest. The metaphor of creator as conductor is on the mark. But he assumes a dichotomy between Woz, the developer, and Jobs, the product czar.

In fact, developers are becoming more like conductors than ever. Now you can aspire to be both Woz and Jobs. And you should.

Let The Music Play

Steve Wozniak wrote the BASIC software that popularized the Apple ][ in binary code—that’s a first-generation programming language. We’re now on to fourth- and fifth-generation programming languages, all built on higher layers of abstraction so we can spend less time with the mechanics of code and more with the problems we want to solve. Likewise, we’ve seen the rise of integrated development environments and drag-and-drop development tools. The barriers to creating full-featured applications has never been lower. 

As a result, fewer and fewer developers are in the business of actually building applications from the ground up. I saw this as a visible trend at the recent API World and Integrate 2015 conferences, which attracted thousands of developers and fueled an active discussion on this very topic.

Developers not building applications—at least in the traditional sense—isn’t as absurd as it sounds. Borrowing from a musical analogy, developers today act less like Woz, patiently typing 1s and 0s for hours at a time, and more like Jobs—pulling together pieces of software created by others into a cohesive whole.

The role of a conductor is, in essence, the orchestration of musical “services” contributed by different instruments. The goal is to assemble all the individual musical components into a package that can be appreciated and consumed by the intended audience.

Here’s why this is exciting for developers: Conductors often don’t play an instrument themselves, but that doesn’t stop them from teasing out a magnum opus from the players seated before them. Similarly, developers can create an application masterpiece by tapping into the expertise of their virtuoso peers, foregoing the need to learn and build every single part from scratch. 

O Brave New World, That Has Such Apps In’t! 

Developers today have plenty of options when it comes to choosing their “instruments”: ubiquitous REST APIs, composable microservices, mobile backend-as-a-service, among many other tools. 

Of course developers aren’t the only ones benefitting here. Companies can develop applications much more quickly and realize far more ambitious technology projects, without having to track down an army of highly skilled experts.

This brave new world of composing applications, instead of constructing them, isn’t without its challenges. As developers worry less about creating complicated functionality from scratch, they inherit the mandate to closely examine the source of the components they’re planning to integrate. They must further think about the connective tissue and the methods of integration.

Fundamental concerns about security get more complicated as data traverses multiple systems. Similarly, scaling becomes a lot less trivial as overall application performance may be dependent on several third party services and the responsiveness of their corresponding APIs.

For anyone developing software for enterprises, this approach will trigger questions around procurement and support, not to mention the need to ensure that legal restrictions and policies are complied with across all the different parts of the solution. (This is where the truly Jobsian conductor might get frustrated.) 

Selected thoughtfully, however, the right tools combined with a complimentary architecture can do much more than just lower your cost and time to market: It can make you future-proof. The problem with a monolithic, handcrafted stack is that it becomes difficult to swap out pieces of it without impacting the entire application. By contrast, assembling autonomous services preserves the option to upgrade individual components and continuously improve the whole system.

Software mashups aren’t a new concept, but it seems that they are finally moving into the mainstream. Large companies and startups alike are looking to take advantage of the plethora of new services and capabilities available through mobile technology and the Internet of Things—and they’re no longer just relying on highly trained specialists to make this happen.

Instead, tomorrow’s most sought-after developers may end up being the conductors who are able to create an app symphony using software they didn’t invent and code they didn’t write. For that, you need someone who brings the best of Woz and Jobs together.

Photo via Steve Jobs

Editor’s note: While Built.io is currently a sponsor of ReadWrite’s Code section, Baier submitted this post independently through ReadWrite’s established guest-post program. As an editorial program, our guest posts are separate from our advertising programs.

Facebook Comments