I saw a link to this via ActionScript Hero, and was intrigued enough to read the article. It’s an interesting review of Gartner’s Application Development Summit, held in Phoenix this week.
I’m particularly interested in what the keynotes were saying about the “future of application development”.
But when they say “agile,” they may not mean the same thing you do. According to the presentation notes, Veccio and Hoyle say that the keys to unlocking the agility paradox are architecture; a focus on software process and engineering; and reuse — of everything. In the past, they maintain, we’ve been builders of custom software, or deployers of packages. According to the keynote presenters, in the new, agile application development lifecycle, reuse and assembly are key. “Application development organizations can’t code themselves into the future!” they write.
“The future of application development is not about programmer productivity,” said Hoyle during the keynote presentation, “but in assembling functionality from components.” While programming will not go away, he stressed, programming has decreasing importance in delivering excellence. “Assembling, buying, and extracting is an increasing part of what you need to do,” he said. To be more agile and responsive, application development managers have to manipulate, orchestrate, and compose new business processes, using resources available from outside partners, third-party applications, Web services, and existing code components. Veccio asked, “Why would you ever code an app from scratch again? Why would you need to?”
Quite frankly, I don’t quite disagree - reduce, reuse, right? Recycling is completely en vogue now (as it should be).
But there’s something missing from this equation: who is their audience?
See, if you’re talking about enterprise IT departments (omg, wtf are those?!?!), yeah - I completely agree. Writing software to run your own enterprise is generally going to be a ridiculous proposition. Chances are you won’t have the manpower to write all your applications, or even to assemble “resources available from outside partners”, support them, and maintain the company network. Some IT departments have enough trouble just maintaining the networks (or so I’ve heard). From that perspective, absolutely: third party wins everytime. Assuming, of course, you’ve got a good third party (or, more likely, a bunch of good third parties).
Everybody in Enterprise IT should have a good party every once in a while.
But while “things” tend to be greater than the sum of their parts, you can’t expect to push forward by assembling the same old pieces in different ways. Sure, you could hook things up a bit better, tighter or looser (depending on your preference), but, at the end of the day, you’ll be completely limited by what’s already there.
Enter the third parties: these are the guys that are going to have to write code. Good code. Code that can be integrated with other providers (well, ok, not code per-se, but applications). It’s the third parties that are going to need to maintain the development roles. Without that, there is no future, no innovation.
It’s obviously not just the third parties, of course. Though I’m really thinking about Microsoft and Google (and, yes, Sun, and OSS providers as well), but they’re technically third parties in this instance. Granted they write software that they themselves use, but they’re really just third parties for the planet.
And I’m completely not against buying software or software components (either as a consumer or as an enterprise). How many large companies write their own accounting software? How many of the ones that do don’t focus on writing accounting software? None. Look at Google and Yahoo - brilliance in picking up application from people writing software (think Flickr, Picasa, etc).
What I’m getting at is that their [read: Gartner keynotes] model doesn’t work if no-one is in trenches writing code. Solid code. Effective code. New code, in particular. Pushing the boundaries, adding new capabilities that were impossible to achieve by stringing together a chain of sufficiently loosely-coupled web services. “Why would you ever code an app from scratch again? Why would you need to?” Aside from the pure pleasure of starting with a blank canvas and seeing where you can go? How about because the app you’re about to write doesn’t exist? That’s a good reason, isn’t it?
Bah. Read the article. Let me know what you think.
Hit it @ devsource.com
If you play guitar (like I do, or, rather, better than I do), in your forays into learning guitar you've probably read some tablature, and possibly even written some of your own. I remember when I discovered the internet, one of my favourite things to do was download tabs for songs I wanted to learn; the format was generally horrible, requiring mono-spaced fonts, but everyone writing the tabs had a different way of doing things (notation for bends, hammer-ons, etc), which made it an awkward experience at best. Sure, you could translate it while you read it, but for anything beyond simple chordal notation it left quite a bit to be desired.
Yeah, I know what you're thinking...Jay has had nothing to say for how long, and now he blurts out with a Vista post?