Fixing bugs, the on-demand way

It's not just product updates that come faster with on-demand applications. Bugs get fixed fast, sometimes in less time than you'd spend just holding to get through to tech support at on-premises vendors. Here's a story from Bill Appleton, CTO of DreamFactory, which just released an AppForce-hosted collaboration tool called DreamTeam. He emailed in response to my posting last week about Microsoft's death-twitch update cycle:

"Phil, I loved your comments about the 9 month innovation cycle. Yesterday a customer reported a bug in DreamTeam, and while they were on the phone I fixed it, they hit refresh in the browser and had the fix. Actually all our customers had the fix. That's just business as usual in the on demand world..."

Ah, but what about testing? I asked, knowing that if I didn't, the point would be raised pretty darn quick by some Talkback poster. Bill had an answer ready:

"You are right, we normally test for a few days up to a week, depending on the situation. Another consideration is having a rational release cycle that can be explained to end users. This was an isolated bug in a new feature, so it was safer to fix, because we weren't going to make things worse in this case. "

That illustrates another advantage of being an on-demand vendor: since you host the software, you're in a position to see whether any customers are actually using a feature, so you can quickly assess the risks of making a change on-the-fly. Bill went on to note that the architectural choices made by on-demand vendors also contribute to keeping them agile:

"I also notice a big difference between regular software and software built out of web services. With regular software, touching anything is likely to break something else. Brittle design requires deep regression testing. But with services, the loosely coupled nature of the service architecture flows through to the application design, or at least it should. If you have an application that is really built out of services, then it's easier to change one module with a degree of confidence that you didn't break another module somewhere else."

Of course, conventional on-premises software vendors already realize that this is an advantage and are straining to rearchitect their legacy code along service-oriented lines. These projects, variously named Fusion, NetWeaver, Nexus and Dynamics are due to bear fruit sometime between 2007 and 2012, if anyone can be bothered to wait that long.