LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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.


Share this link: http://www.sdtimes.com/link/30806
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading