Just because you have a $1 million dollar software budget, it doesn't necessarily mean that you can develop better software than a similar company with a $100,000 budget..."This new system is driving me crazy!" Janet, the hotel desk attendant, muttered as she punched at the keyboard buttons. She looked back at me, flashing her best customer smile. "Sorry, it will be a minute."
She returned to scowling at the keyboard. Apparently the system finally accepted her input; she looked up at me with a satisfied expression. There was a pause as we waited for the system to respond. A long pause.
To fill the time, she asked, "So Ms. Hendrickson, what do you do?"
"I work with software development organizations to improve software quality."
"OH!" she exclaimed. "I wish you were at corporate. I don't know what they were thinking. This new software was supposed to be an improvement, but it's much worse than the old system. It's slow, and I can't figure out what it wants from me half the time."
I involuntarily began imagining the process at corporate.
A 15-person Steering Committee directed a five-person Requirements Task Force to analyze the business and user requirements. The Requirements Analysts sent out surveys, poured through help desk call records, and even interviewed a few users. They produced an 83-page tome that they handed off to the Designers.
A three-person Design team wrote a specification answering the requirements. The 96-page specification was nominally written in English, but because of the amount of jargon used it required a translation guide. The Design team sent it out for review with a deadline for comments. The specified date passed with no comments from the Steering Committee or the Requirements Analysts (who were off to new assignments so they couldn't spare any more time for this project anyway). The specification went to the Programmers.
The Programmers implemented to the specification. There were a few things that were very difficult to do, so they compromised. It would be no big deal if users had to enter a few more keystrokes to access that information, right?
Then the Testers were given two weeks to test it. It took most of the first week to figure out how the new software worked. They found a few bugs, but no show-stoppers. The Programmers fixed a few things and the software was deployed to the field.
That's where Janet comes in. Janet doesn't know anything about the ins and outs of creating software. She probably doesn't want to know. She just wants to serve her customers well. And this software is not helping.
Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don't see is Janet's pain.
All this flashed through my mind in an instant. I looked back at Janet. "Have you called corporate to tell them what you think?" I asked.
"What good would that do?" Janet sneered. "I'll wait on hold for 25 minutes before getting to someone at the help desk. And they're never much help. No, I'll deal with it. Maybe it will get easier. They're sending me to training next week."
So the feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they'll detect catastrophic problems that cause servers to go down. But they won't see the little things that cause long queues at the front desk of the hotel.
If we interviewed the team that created the system, they'd say: "This is our best release ever. We did all the right things. We analyzed requirements and wrote specifications before writing the software. We tested the software before we deployed it. How could the result be wrong?"
How indeed?
Perhaps important nuances were lost in the requirements and specifications verbiage. Perhaps the ship criteria, "no showstopper bugs," could indicate either "solid code" or "not tested." And perhaps the lack of a feedback loop from the field means they have no way of knowing how the users like the new system. "We've been deployed for a month and had only five calls!" the team crows. Like a broken pipe, they see only the trickle of complaints that make it through and miss the flood of complaints leaking away.
Of course, all this happened in my imagination. But I've seen it happen in reality. Ironically, organizations that control their software development process tightly don't necessarily serve their users any better than organizations that cobble something together and throw it over the wall. It's easy to become so tied up in process that we forget the reason for building the software in the first place. Unless we close the feedback loop, we don't really know whether what we've produced is really any good.
Just ask Janet.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
More HTML Articles
More By Elisabeth Hendrickson
 developerWorks - FREE Tools!
|
Join this webcast, to learn how the Rational Process Library can help with compliance issues, drive process improvement, and assist in service-oriented architecture (SOA) or Agile development. We will take a peek into the Rational Process Library with content around software and systems engineering (including RUP), operations and systems management, program and portfolio management, and asset and SOA governance.
FREE! Go There Now!
|
|
|
|
Learn to enable users to both rate existing animations and to combine existing animations into new snippets. This is the third in a series of three tutorials that chronicle the building of a site that enables collaborative discussion and animation building using Domino and OpenLaszlo.
FREE! Go There Now!
|
|
|
|
Build secure Web services with transport-level security using IBM Rational Application Developer V7 and IBM WebSphere Application Server V6.1. Follow this three-part series for step-by-step instructions about how to develop Web services and clients, configure HTTP basic authentication, and configure HTTP over SSL (HTTPS). This first part of the series walks you through building a Web service for a simple calculator application. You generate and test two different types of Web services clients: a Java Platform, Enterprise Edition (Java EE) client and a stand-alone Java client. You also handle user-defined exceptions in Web services.
FREE! Go There Now!
|
|
|
|
Download a free trial version of IBM Rational Developer for System z, software that can help you deliver core development capabilities; the power of Java Platform, Enterprise Edition (Java EE); and rapid application development support to diverse enterprise application development teams. With comprehensive development tools to help create, deploy and maintain traditional enterprise and composite applications, Rational Developer for System z enables developers with different technical backgrounds to easily participate in important technology projects.
FREE! Go There Now!
|
|
|
|
Join this Rational Talks to You teleconference on November 29 at 1:00 pm ET to participate in an interactive discusssion with Grady Booch around architecture and reuse. Get your questions answered!
FREE! Go There Now!
|
|
|
|
Learn the basics of the IBM Customer Information Control System (CICS). With a hands-on exercise, learn how to get your first CICS application up and running on your desktop using TXSeries V6.1 for Windows. The tutorial shows you how to download and install a free trial version of TXSeries V6.1.
FREE! Go There Now!
|
|
|
|
As organizations have grown increasingly dependent on online software, the risk of malicious attacks has also become far more serious. Fortunately, well-governed organizations can protect their Web applications by injecting vulnerability assessments and ethical hacks into their software development and delivery processes. This paper describes 12 of the most common hacker attacks and provides basic rules that you can follow to help create more hack-resistant Web applications.
FREE! Go There Now!
|
|
|
|
Get a free trial download of the latest version of IBM Rational Functional Tester V7.0.1. Rational Functional Tester is an automated functional and regression testing solution for QA teams concerned with the quality of their Java, Microsoft Visual Studio .NET, and Web-based applications.
FREE! Go There Now!
|
|
|
|
The discipline of assembling and delivering software is maturing beyond standard developer-centric compile/test software builds. The end-to-end software development lifecycle is emerging as the new focus moves “Beyond the Build.” Join this on demand webcast to learn about methods for streamlining software delivery and key capabilities of the IBM Rational Build Forge framework for automating build and release management in environments of any size.
FREE! Go There Now!
|
|
|
|
Explore how Rational and WebSphere software enable enterprise documentation in SOA environments. Specifically, a new integration between IBM WebSphere® Business Modeler and IBM Rational® Method Composer software can help technical writers more easily keep enterprise operations manuals in sync with changes that are made to business processes, resulting in more accurate and timely documentation that benefits the entire enterprise.
FREE! Go There Now!
|
|
|
|
All FREE IBM® developerWorks Tools!
|
/ 2 
