Gartner: Software development will cease to exist
Perhaps Gartner research director Darryl Plummer should have tried his message out on the folks across the street at NetBeans day (a prelude to JavaOne) before going out on a bit of a limb by saying software development will cease to exist. I'm rather certain based on the people that I bumped into, roaming around the argent hotel, packing rooms with demonstrations of development technologies like Matisse and Maven, that there might have been a riot. Meanwhile, over at the far more subdued (there was deadly lack of any energy) Gartner Symposium/ITxpo, no one seemed to dispute Plummer's conclusions. Particularly after he very clearly advised Gartner attendees to rent software as a part of a Software as a Service approach to software delivery. Said Plummer as a part of Gartner's explanation of a strategic IT trend pair (software delivery and development styles):
Software as a service is a delivery style that's about three guiding principles:
Plummer's explanation was a bit windy for me as got into the semantics of capabilities versus features and eventually ended up describing -- without mentioning the word mashup -- how business value and agility will evolve and improve as the result of the ability to mix and match service-oriented software components into a final solution that solves a business problem. Plummer drew a picture of a world -- using eBay as an example -- where non-programming mortals used granualar modules of software to align the final solution with their business needs:
Most people don't realize that people putting their auctions up on eBay can change the look and feel of feel of their auction at will. They can change the payment mechanism. They change the way pictures are displayed. They can change how you actually pay for it, what kind of credit services you use at check out. All those things with no programming required. Certainly the community is evolving eBay on its own. This creates a virtuous cycle. The virtuous cycle starts at new delivery models and new development styles and ends at self-evolving communities. This represents the consumerization and the commoditization of development and programming...ultimately, development itself will cease to exist.
The idea that the need for programmers will go away has always been a bit far fetched to me. If for example, you buy Plummer's pitch about seeking out capabilty versus features (do we really need to speak abstractly about "I need a credit card processing component), sooner or later, someone has to develop that capability. The value at the end of the software chain is very much programmer driven... probably by one of the programmers across the street at NetBeans day. Will development get easier? Yes. Will mere mortals be able to do it wthout coding? To some extent, yes. For example, in the mashup world, enablers like Ning.com and mapbuilder.net can help mortals to bridge a skill gap that before seemed unbridgable. And, actually, I think Plummer's intra-domain example of how end users can do a little tuning to their auctions was a super bad example of the promise of componentized architectures and the mixing and matching of capabilities that he described. Far more interesting to me, and I think to businesses of all types, is how such capabilities can cross domains to deliver real business value that, as Plummer pointed out, creates new opportunities.
The better example I'm thinking of is how outfits like MyStoreRewards.com and Paycodes.com leverage PayPal's componentry to deliver business value in the form of customer loyalty to small businesses in a way they never could before (loyalty programs are typically the domain of large retailers). That's an easy-to-leverage capability that's driven by multi-domain componentry with the caveat that the business processes that MyStoreRewards and Paycodes have "digitized" are business processes that required a significant amount of programming before that business value could be derived.
Finally, if software development ceases to exist, then, about the only next logical conclusion we can reach is that so too will large research analyst firms. Personally, every time I talk to Stephen O'Grady or James Governor over at Redmonk and they very righteously disclose whether or not a company they're talking or writing about is a client (something Gartner hardly does), I can't help but think the days of those large outfits are pretty much over. Redmonk is an outfit of three people whose clients read like the who's who of the IT business, probably with billings to match (not match the three person size, match Gartner's billings to those same clients). Three people versus thousands of people. And this (Gartner) is a company that's now about to get another round of investment in a second public offering?