Contents
15.1 Role of Productivity Tools in Rapid Development
15.2 Productivity-Tool Strategy
15.3 Productivity-Tool Acquisition
15.4 Productivity-Tool Use
15.5 Silver-Bullet Syndrome
Related Topics
Rapid-development languages: Chapter 31
Reuse: Chapter 33
Design to tools: Design-to-Tools
Summary of tools group: Chapter 40
SOFTWARE MANAGERS AND DEVELOPERS ARE DRAWN TO productivity tools like ants to a picnic, children to mud puddles, and late-night TV lawyers to auto accidents. Sometimes they're drawn to productivity tools the way that drunken sailors are drawn to the sirens' call.
Productivity tools make up the technology dimension of the people-process-product-technology foursome—and as such, they have a significant role to play in rapid development. Adopting a new tool can be one of the quickest ways to improve productivity. But it can also be one of the riskiest.
The most productive organizations have found ways to minimize the risks and maximize the productivity gains. Their strategy depends on recognizing three critical realities:
Productivity tools seldom produce the schedule savings their vendors promise.
Learning any new tool or practice initially lowers productivity.
Productivity tools that have been discredited sometimes produce significant schedule savings anyway, just not as significant as originally promised.
The rest of this chapter explores these realities in detail.
Computers are good at automatic, repetitive tasks. Most of the things that software-development technology has automated so far have been the repetitive tasks—conversion of assembler code into machine language, conversion of high-level language code into assembler, creating database descriptions from English-like descriptions, handling the same kinds of window-processing calls again and again, and so on. But there are many aspects of software development that are not repetitive and that are therefore not well suited to being automated by hardware and software tools.
In 1987, Frederick P. Brooks, Jr. published the article "No Silver Bullets—Essence and Accidents of Software Engineering," and that article has become one of the most influential and famous articles in the field of software engineering (Brooks 1987). Brooks argues that the difficult part of software development arises from the fact that a computer program's essence is a set of interlocking concepts—data sets, relationships among data sets, algorithms, and functions. These concepts are highly precise and rich with detail. The hard part of software development, Brooks says, is specifying, designing, and testing these concepts themselves.
A different Brooks, Ruven Brooks, published a study that suggested it would take on the order of tens of thousands or even hundreds of thousands of rules to capture the knowledge of an expert developer (Brooks 1977). Capturing the end-product of thinking through all these rules in a programming language is the easy part of software development. Thinking them through in the first place is what's difficult.
The fact that software programs are highly precise and rich with detail is not going to change. Software programs are becoming more precise, more detailed, and more complex, not less. Someone has to think through the conceptual essence of any new computer program or any change to any old computer program. That person must understand each detail of the program's functionality and must understand how each of the details relate to each other. Such understanding is difficult, error-prone, and time-consuming. The time required to achieve that understanding is one of the main contributors to the time required to complete a software-development project.
Fred Brooks maintains that to achieve a dramatic reduction in development time, a new technology would have to simplify the essence of software development; it would have to make it much easier to formulate the set of interlocking concepts that make up a computer program. As a rule of thumb, the more a technology strikes at the essence of what makes software development difficult, the more effort it is likely to save.
CROSS-REFERENCE
For more on rapid-development languages, see Chapter 31, "Chapter 31.
A high-level language compiler saves a lot of effort because it moves the whole set of concepts that you have to be concerned with to a higher level. That's what the move to higher-level programming languages has accomplished over the years. The switch from low-level languages like assembler to higher-level languages like C and Pascal freed you from having to think about what the underlying machine was doing when it ran your program. The move to visual-programming languages such as Delphi, PowerBuilder, and Visual Basic provides a similar kind of simplification, allowing you to forget about many of the tasks a windowing environment performs when it runs a graphically oriented program.
Tools that do not strike at the conceptual essence—the hard part of programming—don't help as much. A programming editor helps only a little because it allows you to type in code faster; it's handy, but it doesn't strike at the essence of what makes software development difficult. The same is true for source-code control tools, debuggers, execution profilers, automated testing tools, and so on; those tools provide only incremental productivity gains for the same reason.
Tools such as CASE tools and code libraries or class libraries are somewhere between high-level languages and coding tools in their ability to improve productivity—they strike at the root of the problem, but most of them don't strike very hard.
Fred Brooks pointed out that our industry has been involved in a long search for a magic silver bullet to slay the low-productivity werewolf. Alexander the Great wept because there were no more worlds to conquer. In 1987, Brooks asserted that, although it had been done before, no single technology or practice looked as though it would be capable of producing a 10-fold improvement in productivity in the next 10 years. Rearranging the math a little, Brooks was arguing that no single tool or practice could produce a sustained productivity improvement of 25 percent per year for 10 years. Eight years later, in 1995, he reaffirmed that position, and I think he's right. We have to be satisfied with individual practices and technologies that generate productivity improvements of less than 25 percent per year, or we have to look for combinations of practices and technologies to have any chance at greater improvements.
Productivity tools tend to focus on software construction. How effective they are in supporting rapid development depends on how much of your project consists of software construction. How large is your project? How complicated is your project? How much of the lifecycle is occupied by software construction? Some kinds of projects are better supported than others.
CROSS-REFERENCE
For details on the portion of a project taken up by construction, see Where the Time Goes, Where the Time Goes.
DBMS-oriented applications. Database applications are well supported by productivity tools on nearly all platforms. Productivity tools exist to generate database schemas, generate queries, format reports, create data-entry screens, and so on. If you need to develop 100 data-entry screens for use with a database, I can't imagine coding that sort of thing by hand anymore because many good database tools (such as Visual FoxPro, Access, PowerBuilder, CA Visual Objects, FileMaker, Focus, and a raft of CASE tools) take the repetitiveness out of that process.
Custom applications. Rapid-development languages work well for small applications in which the design envelope is well understood. If your customer will be happy with standard data-entry forms, standard graphics, standard reports—in short, with an application that looks like a lot of other applications—then you should be able to develop it in a 4GL or visual-programming language. In many if not most custom-software projects, the customer is willing to accept a few limitations in look and feel in exchange for dramatically faster development time.
Throwaway prototyping. Rapid-development languages are extremely well-suited to the development of throwaway user-interface prototypes. You'd almost have to be crazy to develop a throwaway prototype in C/C++ or plain Pascal these days. You might develop the nucleus of an evolutionary prototype in those languages so that you could extend it later on, but it's hard to imagine why you'd use anything other than a visual-programming language to develop rapid iterations of a user-interface design that you planned to throw away later.
In general, the smaller and simpler the application, the more valuable productivity tools will be. On small projects, most of the project is consumed by code construction, which is the part that is usually helped the most by such tools. On larger projects, a smaller proportion of the project is devoted to coding, so the potential contribution of code-focused, rapid-development tools will be smaller.
"Three steps forward and two steps back" is a fact of life with productivity tools. Productivity tools giveth, and productivity tools taketh away.
On one project, my team used a user-interface class library for the Microsoft Windows environment. Using the class library generally made our lives much easier. But then we got to the part of the project where we were supposed to copy graphics from our application to the clipboard in "metafile format." The class library advertised support for metafiles, and its technical documentation said that it supported metafiles. But when we actually tried to use metafiles, they didn't work. Our full-screen metafiles came out about 1/8 of an inch square.
After many calls to the class-library company and to Microsoft, we eventually determined that both Microsoft Windows and the class library contained errors in handling metafiles. We then spent several days designing and coding a workaround to the problem. By the time we got to the metafile work, we were so thoroughly committed to our design that we really didn't have any alternative but to code the time-consuming workaround the way that we did.
On balance, we still saved a lot of time by using the class library. But in the metafile area, if we had known at the outset that metafiles were poorly supported, we would have designed our program differently, and we wouldn't have wasted as much time.
I haven't seen any systematic study of the issue, but my best estimate is that if you plan to use a productivity tool, you should add about 25 percent on top of the total time you expect to spend working with the tool for use in working around the tool's limitations. There are always things that are harder to do because you're using a tool, and sometimes there are defects in the tool itself.
When you weigh the advantages and disadvantages of productivity tool use, the argument for emphasizing productivity tool use on rapid-development projects is far from clear-cut. In a review of 10 software projects that several organizations had selected as their best projects, Bill Hetzel concluded that, "Best projects do not necessarily have state-of-the-art methodologies or extensive automation and tooling. They do rely on basic principles such as strong team work, project communication, and project controls. Good organization and management appears to be far more of a critical success factor than technology" (Hetzel 1993). Other studies have also concluded that productivity tools are only a secondary contributor to an organization's overall level of productivity (Zelkowitz, et al. 1984, Zawacki 1993).
Charles Symons reinforces the point when he reports that there are so many other influences on a software schedule that there isn't any clear-cut data to support the contention that projects that use fourth-generation languages are delivered any faster than projects that use third-generation languages (Symons 1991). This is not to say that specific bits of functionality on those projects aren't developed faster—just that any significant variations in schedule are more likely to result from differences in planning, management, requirements specification, and a host of other factors than they are from the technology used to construct the system.
In a 17-year study involving more than 100 experiments with live projects and 50 technologies, NASA's Software Engineering Laboratory concluded that improvements are characterized by continual, sustained, and methodical change. We should not wait for or depend on technological breakthroughs (Glass 1993).
Leading-edge productivity tools can play an important role in shortening development schedules, but it's good to keep their role in perspective. By themselves, they are neither necessary nor sufficient for achieving rapid development.