Sprinting Toward Second-Rate
A product is only as good as its specifications.
Just as architectural engineers can join lengths of steel to span a river or bend sheets of glass and titanium to form a curvaceous shell for a concert hall, software engineers can build almost anything, but the more they know about how the finished product will be used, the better it can be. Simply having a business analyst describe the optimal set of features and functions is an incomplete charter. Technologists need to know more in order to build an information architecture that’s practical, comfortable, and appropriate for the people who will inhabit it for hours at a stretch.
As with so many other ventures, the ultimate success of a software development project is often determined at the outset. Unless the requirements document for a new information system contains the same sort of detail that architects elicit from their clients about how people will use the system and how they will navigate within it, the best efforts of brilliant technologists may result in a compilation of functions and features that are inconvenient or even unworkable.
During its short history, the software industry has utilized a variety of approaches to develop its products. Like most professionals, computing technologists have invented their own jargon to distinguish themselves from other practitioners and to brand their activities and their products. The software industry has given its development processes active, muscular names inspired by nature and sports—waterfall, agile, rapid, sprint, scrum, spiral, and even extreme programming. Microsoft and many other companies call their development process the Software Development Life Cycle (SDLC).
The distinctions among these methods, and their relative merits, are energetically debated by professionals, but the most significant differences among them are essentially a matter of how the work is organized: How many phases of construction will there be? How often will progress be verified?
Any production process can be envisioned as a cascading progression of many small steps, and a generation ago one of the most popular approaches to software development was the waterfall method. Developers who use this method attempt to document all the requirements at the outset and then work through successive phases of specification and coding before proceeding to test the product and release it. The inherent flaw in the waterfall method is that the farther a project progresses and the more massive it becomes, the more difficult it becomes to shift its course in response to changing business requirements and to control the nature of its terminus.
Newer, more flexible approaches such as Extreme Programming, Rapid, and Agile divide projects into segments that can be completed in short bursts of activity, with deadlines as frequent as every two weeks or every 30 days. In these methods the approach is to identify each task, write the code, test the code, and deliver that unit; repeat the process with the next unit; then test both units together and deliver; and so on, until the project is complete. Essentially, this is nothing more than a series of small—extremely small—waterfalls.
All of these methods have more in common with one another than they do with classic processes of product design, a development process in which the human requirements are as important as the business and technical requirements. Most products are designed, tested, and built according to specifications that identify the needs and the habits of their potential customers, and the ultimate success of these products is measured by the response of the people who use them.
One of the most persistent myths in the industry is that if business specialists can define a problem, technologists can deliver the solution. This might seem logical in light of the software industry’s astonishing technical capabilities, and the standard processes of software development are based on this presumption.
If a business needs something as simple as a sales report that will be updated more frequently, the functional requirements can be easily expressed: This is the information the report must contain, and this is how often it must be updated; this is how the information will be entered, and this is how it will be saved.
Once the functional requirements have been defined, the technical requirements can be specified: This is the software that’s needed to organize the sales information, this is the technology that’s needed to compute it, and this is the data architecture that will structure and manage the relationships among all the various technologies.
Missing from this process is an inquiry into the human requirements: How will this report be used? Who will have access to it? Asking questions that might seem obvious can produce some surprising answers. For example, How will people find this report? Is it clearly labeled? After all, what good is a report if it’s labeled with an obscure acronym that makes it almost impossible to locate? Posing questions that range beyond the status quo can yield new benefits: What other information might make this report more meaningful? Responses to these questions can provide information that leads to innovation.
It’s the job of the business requirements and the technical requirements to tightly restrict what the software will do by narrowly defining transactions and the code that does the job—much of what is defined without ever being seen on a desktop screen. By its nature, this is a mechanical process that is insensitive to the limitations and the potential of variable, complex human beings.
Unless the business and technical requirements are informed by human considerations, the finished product will roll off the assembly line, a piece of solid technology that fully complies with every business and technical requirement, before its fundamental deficiencies are discovered or its full potential can be explored. Only a broad investigation of requirements, one that anticipates the needs of the users, will give technologists the information they need to build a first-rate product.
— 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.
