6871 Unfettered developer freedom may be over
Unfettered developer freedom may be over

Unfettered developer freedom may be over

❤ 46 , Category: Software,   ⚑

Ah, the halcyon days of developers as kingmakers, of developers calling all the shots, of developers turning to open source and cloud to route around barriers to productivity (like Legal! Purchasing! Security! Operations!).

Of course, those days never existed. Not perfectly, anyway—and thank goodness. It turns out that in a world increasingly composed of software, developers matter. A lot. They’re not the only thing that matters, but enabling developer productivity has become a key vector in every organization’s success. Which is why, perhaps ironically, the best way to set your developers free may actually be to fetter their freedom.

[ Also on InfoWorld: How to manage software developers without micromanaging ]

There and back again

When RedMonk analyst Steven O’Grady first published The New Kingmakers in 2013, he partly captured the zeitgeist of the age that developers matter, but mostly he promoted a new way of thinking. New to enterprises, anyway. By then, developers had already embraced the empowerment afforded them by open source and, increasingly, cloud. Still, the idea hadn’t quite caught on that developer productivity wasn’t merely a nice-to-have feature but a must-have.

In late 2017, O’Grady could happily report that his ideas had caught on in a big way, but with unintended consequences. The more developers mattered, the more everyone wanted to cater to their needs with new software tools, new open source projects, new cloud services, etc. This meant lots of new developer choice and associated freedom, but that wasn’t necessarily an unalloyed good. As he noted, “The good news is that this developer-driven fragmentation has yielded an incredible array of open source software. The bad news is that, even for developers, managing this fragmentation is challenging.”

See also  BrandPost: Insider Look at Clinical Use Case for Deep Learning Library in Java

Can one have too much choice? Yep.

It’s long been known in consumer retail, for example, that when there is too much choice, “consumers are less likely to buy anything at all, and if they do buy, they are less satisfied with their selection.” Turns out this isn’t just a matter of breakfast cereals or clothing. It also applies to developers building enterprise software. InfoWorld’s Scott Carey writes that “complexity is killing software developers.” He’s right. But what can be done?

Less is more

In a conversation with Weaveworks CEO Alexis Richardson, he related how self-service development platforms are reemerging to help developers make sense of all that open source and cloud choice. By giving developers “a standard, pre-approved environment in which the effort to create an app from an idea is minimal,” he explained, it allows them to “focus on innovation not plumbing.”

“Pre-approved environment”? That sounds like control. Weren’t open source and cloud, in part, meant to overcome control?

That’s one way to look at it, but, done right, a little bit of constraint goes a long way. Just ask Netflix, which has embraced this idea and run with it—over nicely paved roads—as explained by Netflix engineers Ed Bukoski, Brian Moyles, and Mike McGarr:

“The Netflix culture of freedom and responsibility empowers engineers to craft solutions using whatever tools they feel are best suited to the task. In our experience, for a tool to be widely accepted, it must be compelling, add tremendous value, and reduce the overall cognitive load for the majority of Netflix engineers. Teams have the freedom to implement alternative solutions, but they also take on additional responsibility for maintaining these solutions. Tools offered by centralized teams at Netflix are considered to be part of a ‘paved road.’ Our focus today is solely on the paved road supported by Engineering Tools.”

See also  Onfleet nabs $23M to further develop its last-mile delivery software

It’s clear why an enterprise would want to centralize some control over the choices its developers make. Enterprises want “fast but safe,” suggests Richardson, and safe includes making sure “that compliance and security are in place, … containers are scanned, supply chain is verified in the GitOps pipeline, and so on.” It’s also the case that constraining choice is better for enterprises than “using raw AWS [or another cloud], according to Richardson, because if a bank “lets 1,000 app teams loose on [a particular cloud], then they will create 1,000 stacks, all of which need secops to verify.”

Clearly, that would be a mess. What’s perhaps less obvious at first is how enterprise interests in exerting some control can pair perfectly with their developers’ interests.

Enterprises want their “app devs to become super productive so that the time from idea to dopamine is minimal,” Richardson says. Yes, that’s right. It’s in an enterprise’s interest to ensure maximum developer productivity. Just as it’s the developer’s desire to be maximally productive. Interests are aligned.

This brings us to self-service development platforms or PaaS (platform as a service), as we once called them.

A PaaS by any other name

Some enterprise IT leaders “cringe at the notion of developer self-service,” admits Gartner analyst Lydia Leong, because they worry that “self-service would open formerly well-defended gates … and allow a horde of unwashed orcs to overrun the concrete landscape in a veritable explosion of Lego structures, dot-matrix printouts, Snickers wrappers, and lost whiteboard marker caps.” They don’t trust their developers, in other words. Or maybe they don’t trust the guardrails self-service platforms can erect. Whatever the concern, she continues, self-service “isn’t an all-or-nothing proposition. Responsibility can be divided across the application life cycle so that you can get benefits from ‘you build it, you run it’ without necessarily parachuting your developers into an untamed and unknown wilderness.”

See also  Android Studio improves machine learning support

In other words, enterprises that want to give their developers the freedom the cloud affords can couple it with just enough constraint to make that freedom useful.

How to do this effectively? Netflix has provided plenty of advice, but so have others, such as financial services company Finextra, which knows a thing or two about balancing developer freedom with security assurances, given its conservative financial services customers. Or you could set up time to talk with Leong or RedMonk’s O’Grady to ensure you get the balance right between freedom and control.

However you approach it, the point is to stop thinking about freedom and control as impossibly opposed. Smart enterprises are figuring out ways to enable their developers using self-service platforms. Maybe you should, too.

Leave a Reply

Your email address will not be published.

5 × 5 =