Here’s an interesting exercise for you to try at the conference or meeting of your choice: when speaking with any enterprise app dev/platform/server executive, ask them who the single most important consituency for them might be. Who they are most obsessed with winning over.
If you guessed CIO or CTO, you’re wrong. Chances are, whether it’s IBM, Microsoft, Novell, Oracle, Sun, or just about any other major vendor, you’ll hear “developers.” It’s become the stock response to the question, to the point that it’s borderline cliche. As an example, here’s Scoble’s decription of Microsoft’s views on the subject:
So, today, we’re at the same kind of juncture. Apple is kicking our behind once again. How will Microsoft respond?
Steve Ballmer already gave our vision: developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers, developers…
While some of my analyst colleagues take strong exception to this, or so I’m told, I happen to agree with the vendors here. Yes, you still have to play the traditional sales games and schmooze the CIO crowd, but at the end of the day the CIO can be viewed in many cases as a mouthpiece for his constituency – the developers. Don’t agree? Ask yourself this: ever seen a CIO successfully push an unpopular platform or language top down? Me neither. Or at least, very, very rarely. Getting developer buy-in is absolutely critical.
The question in my mind, then, is not whether the vendors are trying to court the developers nor whether they should be – the answer to both is yes, but whether they themselves actually believe in that line. Because frankly, if they do, they’re not doing a great job of demonstrating their appreciation for this central truth. I think most of this stems from the fact that from a sales perspective, developers aren’t all that interesting. As Jonathan Schwartz reminds us, “Developers don’t buy things, they join things.” That’s an accurate view, in my opinion, and I think explains how – despite messaging to the contrary and the best of intentions – developers can sometimes slip to the bottom of the priority list when all is said and done.
Case in point is what longer term readers will recognize as one of the windmills I tilt at regularly (1, 2, 3), simple, RESTian web services. I have yet to hear any vendor – not one – talk to me about how they help developers design, implement and consume RESTian web services. Why is this important? Don’t take my word for it, ask the developers:
Alan Taylor (Amazon Light 4.0):
“The key to REST for me is simplicity,” he said. “It’s the same reason that I picked up HTML. REST may be a little bit sloppy, but you can see exactly what you’re doing in REST, you don’t have to rely on any clients and you can see exactly what you’re getting.” (link)
Jeff Barr (Amazon):
According to Barr, Amazon made plans for its first-generation Web service in 2002, just as the “REST vs. SOAP” debate was in full swing. “There wasn’t yet sufficient evidence to justify choosing one to the exclusion of the other,” he says. As a result, Amazon carefully layered its implementation so that it could support both REST and SOAP side by side. The final choice was left to developers.
After two years, the results are surprising. The platform has attracted more than 50,000 developers, most of whom prefer the REST model. In fact, 80 percent of the calls to Amazon’s Web services are REST-based, with just 20 percent being SOAP-based. (link)
Stewart Butterfield (Flickr):
“On the strictly practical side, I think we had one person inquire about using the SOAP version of the API. I don’t know if any apps were actually built. There is at least one application built on XML-RPC. But all the others–I don’t even know how many there are–are built on the REST API. It’s just so easy to develop that way; I think it’s foolish to do anything else.” (link)
It’s certainly not that vendors don’t have the capability to meet the needs of developers; these are, after all, simple in design and execution. My feeling is instead that they don’t help sell to the IT manager, to the CIO, to the CFO. Or perhaps they’re concerned that the very simplicity of this development paradigm will undermine the utility of their often complex (read: expensive) tools and platforms.
Either way, it amounts to the same thing. Developers not getting what they want and need. If I were working for a vendor (and I guess technically, we do work for several), I’d be thinking about how to allay concerns around potential threats to my platform while providing developers the tools that get them interested, excited and are the embodiment of cool. The developers are telling you what they want, so why not give it to them?
