Quality Software Management, Vol. 4: Anticipating Change

Quality Software Management, Vol. 4: Anticipating Change

by Gerald M. Weinberg
     
 
Change is inherently dangerous. Moreover, change becomes even more dangerous when we don't know what we're doing. Attempts to change software organizations commonly fail because of inadequate understanding of change dynamics — the same reason the organizations got into crisis in the first place.

Jerry Weinberg concludes his series of four stand-alone

Overview

Change is inherently dangerous. Moreover, change becomes even more dangerous when we don't know what we're doing. Attempts to change software organizations commonly fail because of inadequate understanding of change dynamics — the same reason the organizations got into crisis in the first place.

Jerry Weinberg concludes his series of four stand-alone volumes with this pragmatic, comprehensive testament on the fundamentals of change management.

From systems thinking to project management to technology transfer to the interaction of culture and process, this volume analyzes change from a broad range of perspectives, spanning the spectrum of sources of organizational change. Such breadth of awareness is essential for successful management of system evolution.

Editorial Reviews

Booknews
Weinberg closes his series on software management by illustrating how to create a supportive environment for software engineering in which an organization can realize long-lasting gains in quality and productivity by learning how to manage change. He analyzes change from a wide range of perspectives, including systems thinking, project management, technology transfer, and the interaction of culture and process. Annotation c. by Book News, Inc., Portland, Or.

Product Details

ISBN-13:
9780932633323
Publisher:
Dorset House Publishing
Publication date:
04/01/1997
Pages:
504
Product dimensions:
7.00(w) x 10.00(h) x (d)

Read an Excerpt

Chapter 5: Keeping Most Things the Same

...5.2 Exposing the Theory in Use

In organizations, it's not always possible to look at structures and determine their purpose. Some structures acquire purposes for which they were not designed, and these purposes could be either consistent or inconsistent with the organization's espoused goals. In dysfunctional organizations, many structures are created precisely to mislead employees, customers, or higher management. Other structures actually mislead the very people who seem to espouse the opposite of what they produce.

These systems of maintaining cultures of failure and/or management power are examples of what Chris Argyris calls espoused theory versus theory-in-use. The espoused theory behind so-called stretch goals is employee achievement; but the theory-in-use is, Keep the employees under (my) control. The espoused theory behind the failure measurements is quality; but the theory-in-use is, Quality is not really achievable.

A common example of structures that can mislead, either consciously or unconsciously, are project reviews. Although the ostensible purpose of project reviews is to provide accurate information, in many organizations they are used to put a stamp of approval on less-than-secure projects—and thus produce purported information that is anything but reliable.

In order to achieve an Anticipating (Pattern 4) culture, someone needs to expose these hidden purposes. Otherwise, they'll block the path of process improvement. One way to determine the real purpose of a project review is to offer measurements in advance for judgment:

1.   Fill out N summaryreports in advance for N possible action outcomes of the review, plus the names of proposed reviewers.

2.   Present one of the N reports to the manager who will receive the actual report and ask, "What will you do if you get this report?" Repeat the question for all N possibilities.

3.   If the manager isn't prepared, say, to accept a "Discontinue" decision, then you know the purpose of the review is not really to discontinue unsound projects. The same is true for the other decisions. Sometimes a manager isn't prepared to go ahead with an "Accept" decision either, the true agenda being to kill the project or to embarrass the project manager.

What if the manager simply lies? Naturally, managers with hidden purposes may not tell you directly what they would actually do, but you can always tell by their nonverbal reaction. Or they will usually give it away with their words, such as, "Well, of course I would discontinue the project if that's what the review board recommended, but no sensible reviewer could possibly make that recommendation, knowing the political situation." In these cases, find a way to avoid wasting your time doing the project review. If a mock review has to be conducted to cover these lies, arrange to be out of town. Association with sham events cannot possibly help your career as a manager or a change artist.

5.3 Deterioration

Although maintaining an organization may not sound as thrilling as changing one, maintenance is a busy job. It's not sufficient to set up a process and then expect it will go on forever. Without constant tending, any process will deteriorate, and deterioration of the process invariably leads to deterioration of the product.

In an article in Software Maintenance News, Irv Wendel relates an instructive case of an IS department that first renewed itself, and then was allowed to deteriorate:

Procedures within the department changed. Phased implementation brought with it tight schedules that, in actuality, prevented formal walkthroughs; this had been where project standards were enforced. Instead, we held informal one-on-one walkthroughs as time permitted.

The as-time-permitted dynamic for technical reviews, of course, means that those programs that most need reviewing never get reviewed. Even when such programs do get reviewed, the degenerated process means that the reviews are not very effective. Wendel's article continues:

While reviewing changes made to the master file update program made by another programmer, I noted that the changes were of a different style than the rest of the program. I asked the programmer why she had deviated from the program's standardized style. She replied that was how her instructor taught her to write structured code. I pointed out that there were many styles in COBOL that could be considered structured programming. I also delineated the benefits of consistency. She was not swayed....

Despite my disapproval, her modifications went into production unchanged. This incident (and a few others, such as the elimination of our tech writer) indicated that the quality of the system was eroding and would probably erode further, with management's de facto approval.

Erosion of the product leads to further erosion of the process—one instance of which was given in the conclusion of Wendel's story:

Shortly thereafter, I decided that my time had come and I obtained a contract with a different division within the bank.

When the process goes sour, good people go south.

5.4 Design Maintenance Debt

Around 1980, a few Cassandras started crying out about the coming millennium, when all the two-digit date fields would destroy databases and the software that accessed them. It's not always easy to predict the future of an information system, but it was relatively easy to predict that the year after 1999 would be the year 2000. If people had started converting their date fields in

1980, they could have done an incremental change, one-twentieth each year. If they started ten years later, they'd have to have done one-tenth each year. It was within the power of software engineering managers to make this a relatively minor problem, or to make it a crisis. Most made it a crisis.

5.4.1 Design deterioration

Thousands of other more obscure problems of exactly the same nature lurk in old systems. Money fields, for instance, have been subject to inflation. I recall several cases of insurance companies that had systems with two digits for hospital daily room rates (which seems incredible now). They all waited until the systems wouldn't work before they did anything, even though they could see the rates growing for years. Then, in crisis mode, they did a poor, patchy job.

These are examples of design deterioration—design decisions that didn't age well. Other examples that come to mind are faulty design assumptions about the future relative speed of storage devices, lost wagers on the size/cost trade-off in memory, dependence on minor languages or operating systems that run out of maintenance, and hard-coded mappings to human interface devices. Each such shortsighted design decision adds a little to the design debt carried by the existing software inventory.

Perhaps none of these design deteriorations seems sufficiently large or exciting to make an issue over. But as the Scotsman said, "Many a mickle macks a muckle." After a couple of decades of such decisions and little effort to correct them, many an IS organization is in an enormous muckle of Late Status Quo. Nothing will happen until a foreign element is introduced, like the new manager in this story told by Naomi Karten:

At the RST company, I was in charge of a billing system with space for amounts up to $999.99. When it became apparent that amounts were exceeding that and would do so increasingly, we prepared plans for a system-wide modification. Every time we proposed it, it was shot down. Instead, we were told to identify bill totals that would exceed $1,000 and produce a report identifying them so the users could pull those bills and reproduce them manually (and correctly). The system was finally modified (after I left), but not until a new high-level manager took over who heard about the problem and said, "Fix it!"...

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >