Fixing bugs, the on-demand way

Fixing bugs, the on-demand way

Summary: Bugs in on-demand applications get fixed fast, sometimes in less time than you'd spend just holding to get through to tech support at on-premises vendors.

SHARE:
TOPICS: Tech Industry
2

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. 

Topic: Tech Industry

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Famous last words - this bug fix won't affect anything else

    Accepting an untested bug fix on-the-fly is pretty risky. All releases need to go through testing. If I had a dollar for every time a developer claimed his change wouldn't affect anything else..
    archerjoe
  • Testing vs. How Many Affected

    I agree that testing a change before releasing it is extremely important. I assume that Bill made the change in a development envrionment first, then released to a production environment. This also helps track who changed what.

    But our on-demand solutions for phone, data, Web and fax also require us to fix and release in very quick cycles. Loosely-coupled systems are the key.

    Even if the "fix" affects other areas of the system, you fix those. As long as you are not corrupting data (another big issue), then making minor fixes and releasing them will help the software work out its other "issues". That's part of today's rapidly-iterative software cycle that many traditional software vendors have not fully grasped.
    Paul C.