Those Stinking Users - Software Development Times On The Web

Those Stinking Users
By Larry O'Brien

July 1, 2007 — Perhaps the only thing worse than a slow uptake of your application is a smash hit. Users have a way of outfoxing everything, including load tests, and the imperative to respond to existing customers can absorb all the working hours of a team that is scheduled to move on to the next version. Worse, when a product is exposed to an order of magnitude more users than planned and when the product is used more intensely than anticipated, the defect list grows rapidly, potentially panicking the team into treating the symptoms, not the causes. The resulting chaos can easily derail a team, especially one new to agile processes, where “the customer is always right” and being responsive were the values that led to the success in the first place.

Not long ago, I witnessed this very problem. I was engaged to work on the requirements and architecture of The Next Phase, which didn’t seem to have a lot to do with The Current Deployment, whose two big features were a comprehensive audit trail for management and a Web-based “dashboard” that gave users a much better view of their own context. Following the principles of “You Ain’t Gonna’ Need It” and “Don’t Repeat Yourself,” the dashboard and the auditing facilities used the same messages to request information; the dashboard, of course, stripped out the huge blobs of auditing data and presented a much-compressed summary. What was not anticipated (note the use of the passive tense to avoid blame) was that the users found the historical perspective of the dashboard very valuable and configured their dashboards to retrieve not just a day or two of history, but often everything they did in the past month. Further, once the initial group of users saw The Current Deployment, the client company went from a cautious ramped deployment to “We want to give this to everyone, starting Monday.”

Wonderful, right? Well, not so much. The documents coming back to the presentation layer were huge and the response times quickly degraded. A quick look at the server’s performance monitors showed that memory was thrashing terribly—it was paging data on and off the disk continuously.

“Let’s add RAM,” was the natural “Simplest Thing That Could Possibly Work.” Except, I opined, I didn’t think it could possibly work. Max out the RAM? Of course try it. But everything we were seeing pointed toward the situation getting worse, and probably in a nonlinear way, since the success of the dashboard led to further exploration of alternatives, increasing the amount of auditing data that we were storing and subsequently retrieving and then discarding.

The solution, I suggested, was that the dashboard had to work not with the general “all information” request-and-response, but with a new set of queries that were designed to contain just the summary data. They had to push the processing back into at least the middle layer (where it could be cached and shared between clients) and possibly all the way back into the database (where we could, if necessary, even adopt a summarize-on-update strategy that would minimize retrieval-time processing). Not an intimidating task, but certainly not something to be dashed off and slipstreamed into the current deployment. What they could slipstream was a flag to chop the auditing data off at the database layer, a suggestion that made everyone frown in distaste (and, sure enough, turned out to have unforeseen consequences).

The development manager was downcast. Here he had supervised a successful development cycle, resulting in on-time delivery of a product that delivered more value than the customer had anticipated. The decisions made along the way were, individually, reasonable: I hadn’t designed the dashboard messages, but if I had, I would have agreed, “Yeah, summarizing the data is a presentation-layer concern.” They had done load testing and everything had looked great—according to the use cases they’d developed for. Now, suddenly we were looking at delaying The Next Phase for a six-week sprint that felt like we were fixing screw-ups, not just with the dashboard issue, but because the success of the system brought myriad trivial but time-consuming defects (I’ve never seen so many “TO DO” comments flushed out so fast).

As we wrapped up a multihour session that had hardly touched upon The Next Phase, I could see the frustration on his face and I knew what he was thinking: Software development would be so much easier if it weren’t for those stinking users.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/15/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

Interop New York
9/15/2008 to 9/19/2008
New York
TechWeb

VMworld 2008
9/15/2008 to 9/18/2008
Las Vegas
VMware

Mobile Business Expo
9/16/2008 to 9/19/2008
New York City
TechWeb

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA