![]() |
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Capital One sponsored this post.
Developers, developers, developers!
Technology vendors have screamed for more developers ever since it became clear that they’d become a lot more influential in the technology landscape. It was Microsoft who coined the phrase “developer ecosystem” in the 1990s. This environment for developers became a foundation that fueled Microsoft’s growth, enabling it to become a juggernaut that was the envy of technology companies worldwide. Ever since, every large technology company has dreamed of owning the developer space, with its attendant influence and center of gravity that is shaping the future of enterprise platforms.
Many companies have turned that tried-and-true playbook into success. Microsoft created consistent APIs and a wealth of developer documentation so that thousands of consultants and independent software vendors could build customer bases on Microsoft’s significant operating system market share. VMware created an easy way for developers to build and deploy apps right from their workstations, without the need for interference from stingy ops people. Apple created the world’s most successful small device operating system, iOS, and used its leverage to turn its third-party marketplace into a market force that sustains its continuing growth. Amazon created a massive compute infrastructure that gave developers even more control over their software development lifecycle, building a vibrant tech garden where a million startups grew. All these examples have a few things in common:
The critical question to ask (and answer) with any developer relations program is straightforward: Can developers use your tools to deliver more value in a shorter amount of time?
This question seems relatively simple, but let’s examine what it doesn’t ask. Many vendors have developed snazzy, whiz-bang tools for developers, but the most significant factors are a compelling platform (that developers actually want to use) and shorter time to value. In these instances, the platform attracts developers, who drive platform growth in a symbiotic relationship that fuels a positive feedback loop.
Can you be successful as a technology company without developers? Sure, but the examples above demonstrate wild success — levels of success that are difficult to imagine without a strong developer community. It’s safe to say that how well you operationalize developers can mean the difference between modestly succeeding and wildly exceeding expectations. Developers have significantly increased in importance; and in a world of technology kingdoms, enterprise developers are kingmakers.
This begs the question: What does the enterprise developer want?
Enterprise developers want power and simplicity. They want tools that ease their pain and allow them to focus on writing code without too much overhead. But the enterprise developer in 2021 wrestles with too many choices, increasing complications, and too much overhead.
Today’s developer market is an interesting mix of platforms and tools in a minefield of developer experiences. Today’s enterprise developers use old software libraries because those old libraries work, despite potential vulnerabilities. Because everyone has adopted DevOps principles, they are all saddled with maintaining their applications over the long haul, dealing with much overhead as a result.
While maintaining their apps in a You Build it, You Own it (YBYO) universe, they’re also resolving the same issues with common libraries that hundreds of other discrete teams are addressing concurrently. For example, every development team affected by a bug in a specific library will spend time manually patching and fixing the software.
Because vendors haven’t addressed the open source sustainability problem, they don’t prioritize contributing fixes upstream — and most large corporations haven’t figured out how to integrate upstream fixes into their everyday workflow. The mantra “write once, run everywhere” has become “write a hundred times, deploy a hundred times, fix and remediate a hundred times.” The paradox of choice has led enterprise developers down a path that they simultaneously adore and loathe.
Complexity often goes hand in hand with large-scale computing, but much can be done to improve the developer experience.
Let’s go back to the central thesis: How to operationalize the enterprise developer. Turning to the previous theory that a compelling platform and developer ecosystem leads to wild success, what would a successful developer platform look like? It would:
Looking at the computing landscape now, any given solution could conceivably serve the purpose of easing developers’ pain while also allowing them to deliver value more quickly. It seems the easiest path is a platform that utilizes cloud infrastructure and wins developer hearts and minds, by integrating seamlessly into their existing tools and workflows. In short, the winner will be a cloud accelerator.
Given the lack of available comprehensive solutions for the developer experience, with none on the immediate horizon, or even a set of reliable building blocks to quickly assemble a solution, what can we do? I’ll cover this in my next article…
Capital One sponsored this post.
VMware and Amazon Web Services are sponsors of The New Stack.
Feature image via Pixabay.