Breaking the Cycle of Failure
How we go about designing a product will directly impact its quality and its success. This is why so many business systems fall short of expectations once they are in the hands of the end users: The process by which they’re designed is defective, and the people who design them are not professionally equipped to do the job.
Most business software is the product of teamwork between two groups of professionals. In one corner are the business experts, knowledgeable in how work is done (or should be done). In the other corner are the technologists, ready and able to code almost anything. Rarely does either group include individuals who are trained in the traditional process of product design. By default, by sheer political might, or by chance—depending upon the organization—either the business side or the technology side will take ownership of figuring out how the software will look and feel. The ineffective result of this collaboration can be witnessed in the many software development methodologies that have been documented, institutionalized, revised, praised, and condemned, all in the name of building better systems; yet every one of these methods is pretty much as ineffective as the others when we consider the quality of the user’s experience with these tools.
Throughout the 1990s, business and technical experts favored a systems development process called the waterfall method. In this process, business experts compile a complete inventory of all the functional requirements of a system, and then technologists write the specifications for a system that will satisfy the software product’s description. These and other prose-based specifications become a thick set of documents that are handed off to a development team who begin the long and often painful process of building this large and thoroughly documented system. Like rivers at the headwaters of a waterfall, the streams of code join together, forming a mass whose course becomes increasingly difficult to alter as it cascades toward its terminus. Eventually, after developers have spent months writing hundreds and thousands of lines of code, the business stakeholders who were involved in the early stages of product definition are brought back into the process to see the results of the developers’ efforts at a stage called User Acceptance Testing. This is where the problems begin to surface.
User Acceptance Testing, or UAT, is possibly the most Orwellian misnomer I have encountered in my career. Typically, no users are asked to participate in this step of the development cycle, and the concern for any level of acceptance by users is marginal at best. Essentially this is a check to ensure that the software code coming out of the development phase can perform every function that was inventoried in the requirement document: For example, Can this application be used to retrieve blood pressure data? This is the moment when the business experts obtain their first real view of the software on screen, and it is among the riskiest junctures in the software development process. Very often, the reaction from the business side is This isn’t what I expected. Not unreasonably, the technologists respond by saying, This is what you asked for, but if this isn’t what you want, tell us what you need. At this point all bets are off, and what happens next is anyone’s guess.
The beauty of prose is its highly variable nature: When a writer assembles words in combination with one another, the choice of one word over another can shift the meaning of what is being presented to the reader ever so slightly, or possibly quite dramatically. A set of words will paint a unique picture in the mind’s eye of every reader; that’s why the film version of a favorite novel may look nothing like the book we’ve imagined. Surely this dynamic is what makes the enjoyment of literature such a personal and immensely popular pastime. Yet this same magic—the ambiguity that allows each of us to visualize something unique in the same set of words—is the worst possible thing that could happen in a product design cycle, and it creates havoc when software developers work from written descriptions.
Business experts and technologists speak somewhat different languages, and as programmers interpret the words describing business requirements, it’s unlikely that their vision of the tool they are programming will accurately reflect the tool that the business stakeholders believe they have described. In User Acceptance Testing, the gap between what the business side had envisioned and what the developers have coded becomes painfully obvious. In the waterfall method, when all these disconnects emerge toward the end of the development cycle, the next stage is typically a combination of responses: Immediately re-work the screen displays if changes can be made without dramatically impacting the software code; devise a training plan to address critical bugs, the glaring issues that can’t be fixed but ones that will most definitely trip up users; and make a list of changes to the product’s “features” that need to be reconsidered in subsequent releases. Or even: Rewrite the specifications and repeat the process.
This situation couldn’t last. Because technologists alone had written the code, they took the blame for delivering unacceptable displays and software applications that were impossibly difficult to use. But the technologists had only delivered what they had been asked to code. Enter the “agile” methodologies, and the age of shared guilt.
Partially in an attempt to solve the problem of not giving the business side an opportunity to see new software products until it’s too late to make changes, developers devised new forms of the development cycle such as rapid, agile, extreme, spiral, and scrum. In these methods, segments of an application are designed, developed, and reviewed for accuracy as teams begin designing and building the next logical piece of the application. Over time, these pieces come together to form the whole system. No longer are thousands of lines of code in jeopardy during a momentous unveiling of the software application; instead, business stakeholders review a sample that is the result of just weeks, days, or even hours of development. If a developer has not coded the written requirements into a user interface that reflects the thinking of the business stakeholders, the scope of reworking that code is not tremendously great. Theoretically, over time, a sequence of well- designed segments of the system will be linked into a well-designed whole.
Sound like a reasonable way to solve the problem? It isn’t. Unfortunately, a component of the system reviewed at any stage does not represent a picture that’s complete enough to make possible an accurate or thorough critical assessment. What evolves is a collection of parts. At this point Victor Frankenstein’s monster may come to mind.
Imagine that you are working directly with a contractor to build a new headquarters building for your company. The contractor has been given a highly detailed document – not a set of blueprints— describing the characteristics of the building, from the number of stories and the square footage of each floor to the grade and the color of the carpeting to be installed in the corridors. Early in the project the contactor has completed the construction of five steps in the stairway that will serve as the emergency exit from the top to the bottom of the building. He calls you in, points to the paragraph of text in the requirements document describing the stairway, and asks you to sign a release confirming that the five steps are “correct.” This would be impossible: You wouldn’t be able to see how these steps will physically relate to the other steps that must be built, how they will be placed within the building, and where they will land the workers as they head for the exits.
It’s assumed that by delivering smaller pieces of a software application through relatively short bursts of design and development, the rapid methodologies of the development cycle will mitigate the risk of disappointing the business stakeholders and in turn the end users. Although these methods may ease the trepidation of the business side over the grandiose unveiling of a system, what is being delivered is of no higher quality from the perspective of the end users. These methods do nothing to expand the shared vocabulary of the business and technology professionals who are performing the work, because they do not incorporate design techniques that allow all the members of the team to visualize the software prior to any code development. So instead we see new systems with no substantial improvement in the quality of the end user’s experience; but now fingers cannot be pointed at just the developers. Because the business team has participated in every stage of the process, reviewing incrementally delivered pieces of the system, they too own part of the blame for systems that ultimately disappoint.
An unintended consequence of the agile development method is the fact that business experts, who used to do most of the finger-pointing when systems failed to resonate with users, are less willing to assume this role now that they share more responsibility. In the resulting silence, everyone is left to believe that the problem is solved. It isn’t.
The cycle of disappointment and failure that sabotages our business technology can be broken only by reconfiguring the standard software development process. Although the waterfall and rapid methodologies have proven tremendously effective in developing computer code, they are weak at best for the creation of human-centered tools.
Every standard method of software development lacks flexibility, affordable and effective modeling of the proposed system, and early proof that the system will achieve business goals through effective use. These are the very strengths of design, the arrows in the quiver of every capable designer. Whenever designers contribute design methods to the development process, and whenever human consumers of the end product are effectively guided to participate in the process from start to finish, the development cycle leads to products that return their investment many times over.
—Excerpted from Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate by Harold Hambrose (John Wiley & Sons, Inc., New York). Order your copy of this book.
