Ben Wen is vice president of product at Joyent, the corporate steward of open-source project Node.js. He prefers Emacs over vim.
It’s been well documented that software is eating the world, but what might not be as obvious is that developers are the ones serving up the meal. Given the networked computer and the Internet, older business models and operational assumptions are becoming less relevant. Software engineers who are feeding the beast need tools to deliver the next tasty morsel to ravenous end users. This model has turned the mobile and web app markets into instant, competitive feature bake-offs. So the question you should be asking yourself is, “How well does my team cook”?
Delivery of meaningful software features is an existentially critical business practice, and it requires precious resources, especially your and the rest of your software engineers’ time and cognitive headroom. Ideally, software engineering practices, tools and environments should maximize the former and minimally tax the latter. That might seem straightforward, but what makes it so important for businesses today is the extreme impact of a single, well-executed, well-timed software update.
As seen by the old and new
From Barry Boehm to Tom DeMarco and Timothy Lister, developer productivity has been well studied (if not well understood; source lines of code, or SLOC, does not count, by the way) and even newly minted software engineers have an intuitive sense of what makes an environment productive for them. In fact, it’s instructive to see what new practitioners are attracted to. Without prior baggage, and with new expectations of performance, memory footprint, and other exponentially improving hardware features, plus the free time to hack, the “rookies” on your teams often see advantages the old guard does not.
Of course, the history of computer languages and programming environments can be viewed as a noisy debate between the old guard (e.g. hand-coded machine operations) and the mavericks (e.g. macro assemblers); between assembly code and high-level languages like FORTRAN, and between FORTRAN and Pascal, between WinAPI and NextSTEP, and so on. (Before Steve Jobs was presenting new iPhones at Apple keynotes, he was arguing about operating systems. Jump to 12:45 of this 1997 MacWorld video for a little bit of pre-turtleneck nostalgia.) In each debate, practitioners with well-honed skills in what was then state of the art often view the new approach with bemused derision. In my experience, some will throw around labels like “toy” or “limited” or “not serious” or “slow” or “OMG dynamically typed!” semi-seriously.
Admittedly, some of those new-fangled techniques and technologies do hang around and make development better. That said, let’s take a look at which some new tools (utensils?) development teams cook with.
A look inside the developer toybox
2. PaaS: The continued rise of the Platform as a Service is also linked to developer productivity. Dismissed in funding and finance circles because of low standalone margins, PaaS is still loved by its users: web developers. Developers love the simple command-line tools and the time they save not having to manage various tiers of infrastructure. PaaS’ are especially interesting because they also represent a shift in the way that developers find and aggregate technical components — not as software, but as live running component services. PaaS may be called something else going forward, but this functional space of simplified, dynamic deployment and configuration is more than a sugary confection.
3. Public component services as APIs: The growing constellation of developer API services are another expanding area of productivity enhancers. Like PaaS, these APIs offload operational details by offering a (usually) simple, well known abstraction on the Internet. Configuration, maintenance, and other issues can be sidestepped, leaving time and energy for focusing your attention to authoring differentiated features that customers care about. That makes APIs the secret weapon of choice for hackathon entries. Part of the challenge of any hackathon is that teams can coalesce on the day of the competition without ever having met previously. In the handful of sponsored hackathons that I’ve observed, productive teams use existing cloud-based APIs and services (like databases, queues, authentication, storage etc.) to very quickly cobble together a competitive entry.
What’s the next model for dinner?
These are just a few areas where the debate for the minds and hands of software engineers are currently being held. The cycle of ever more productive tools, followed by higher customer expectations, carries the need forward into the future.
Software eating your world? Yes, the growth of “software-accelerated” companies is certainly causing shifting profit pools and changing competitive landscapes. Ten years ago, who would have guessed that pink-mustachioed, privately owned cars would be competing with taxi and limousine commissions? Just as Lyft, Uber, and Sidecar hacked the hackneyed hack model, so can your developers hack another industry.
So, what new models will you feed?