‘QSM1’ Category Archives


Signs of Corporate Entropy

by Tony in QSM1

One of the most important things leaders need to learn is to recognize the signals of impending deterioration. I have made a list of these signals over the years. As you read this list, remember that many people in large organizations relish apathy. They often fail to see the signs of entropy:

  • a tendency toward superficiality
  • a dark tension among key people
  • no longer having time for celebration and ritual
  • a growing feeling that rewards and goals are the same thing
  • when people stop telling tribal stories or cannot understand them
  • a recurring effort by some to convince others that business is, after all, quite simple
  • when people begin to have different understandings of words like “responsibility” or “service” or “trust”
  • when problem-makers outnumber problem-solvers
  • when folks confuse heroes and celebrities
  • leaders who seek to control rather than liberate
  • when the pressures of day to day operations push aside our concern for vision and risk
  • an orientation toward the dry rules of business school rather than a value orientation which takes into account such things as contribution, spirit, excellence, beauty and joy
  • when people speak of customers as impositions on their time rather than opportunities to serve
  • manuals
  • a growing urge to quantify both history and one’s thoughts about the future
  • the urge to establish ratios
  • leaders who rely on structures instead of people
  • a loss of confidence in judgement, experience, and wisdom
  • a loss of grace and style and civility
  • a loss of respect for the English language

— M DePree, Leadership Is An Art, quoted in Jerry Weinberg, Quality Software Management Vol 2, Chapter 1


Managing Software

by Tony in QSM1

Why would anyone want to manage software? It can’t be the money. If you’re interested in money, you’d probably do better investing your time in becoming a top developer, rather than taking a chance on becoming a mediocre manager. It can’t be the admiration of your peers, because they’ll probably despise you for “selling out” to management. Over the years, I’ve found very few programmers who went into management for money or prestige. Instead, I’ve met thousands of them who went into management for the same reason so many abused children become therapists. It’s called the “wounded healer” syndrome: You take up healing because of the experience you have with your own wounds.

Programmers go into management because they have a cause: They think they can make the software industry better than it is.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 18


Busy Managers Mean Bad Management

by Tony in QSM1

Managers often say that it’s not their fault that they’re so busy, and they are often right. Outside factors may indeed be too disturbing to be regulated, but that usually because managers at a higher level are not doing an effective job of regulating the outside factors. When upper levels of management pass the pressure down, this is equivalent to holding a blowtorch on a thermostat in an attempt to warm the room. This kind of higher-level ineptness does tend to make it impossible for a lower-level controller to be effective.

Managers who lack self-confidence, of course, will always say that they are busy. It isn’t befitting them to admit to slack-time. You can test the quality of management by interviewing employees and finding out how long they had to wait to see their manager for an unscheduled contact.

If managers do not have a reserve of time, they cannot be managing effectively. In a well-run project, nowhere near a crisis, the managers may put in a full day, but thy have lots of time to damp out crises before they get off the ground.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 17


Stress Control Dynamic

by Tony in QSM1

Every individual has a unique Pressure/Performance Curve, though all the curves have the same general curve. Moreover, it’s not the applied pressure that leads to the Pressure/Performance Relationship, but the perceived pressure. What motivates me to work a hundred hours a week may simply provoke you to yawn.

Physicists make this distinction by calling the applied pressure “stress” and the reaction of the system “strain”. Unfortunately, the medical and psychological literature doesn’t make this distinction and neither do many managers. They use the term “stress” for both applied and perceived pressure, which tends to confuse their understanding of the dynamics involving pressure. When you say “I’m under a lot of stress”, do you mean that a lot of pressure is being applied, or that you are reacting poorly to the pressure? Once we make the distinction between the situation and the reaction to the situation, we can begin to investigate some details of different reactions to applied pressure.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 16


Maintaining Maintainability

by Tony in QSM1

Over the life of a software system, the internal quality of the code is more important than the external quality in determining its controllability. In time, existing code may even come to have negative quality, meaning that it would cheaper to develop new code than attempt to keep repairing the old. Many organizations are holding large inventories of negative quality software, but usually they are unaware of that fact. Or, if they are aware, they are so unsure of their ability to develop new code that they continue to limp along patching ever more pitiful and expensive systems.

They know they must patch, of course, because they know that any system must have its functions maintained. What they don’t understand, however, is that any system must also have its maintainability maintained. Even software that is initially well designed and implemented begins to deteriorate and lose its maintainability in a software culture that doesn’t regularly invest in maintainability.

What has to be maintained for maintainability to be preserved? Besides functional faults and loss of efficiency, other side effects include increases (or decreases) in the size of the code itself, destruction of code quality, loss of design integrity, and obsolescence of documentation. All of these together constitute the decay of maintainability. Quite likely, the loss of maintainability is the ultimate cause of death for even the best-designed, -built, and -maintained systems.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 15


Circulation Dynamics

by Tony in QSM1

YES Systems was a third-party software developer that bid on and won a 90,000 LOC project. It was well underway when the project leader was asked by his manager to add 10,000 lines of new function. Later, YES managers asked me to help them figure out why the total project had been four months late. I put their numbers into a rough simulation.

The simulation assumed (far too optimistically, of course) two things: one, that no new faults are introduced when correcting the ones located; and second, that located faults are resolved instantly. The model also assumed 10 faults/KLOC going into prerelease testing, based on YES’s previous experience on similar systems, and it assumed exactly one System Trouble Incident per fault (which was very optimistic).

In the simulation, then, the larger system thus starts with 11% more code and 11% more faults and generates 11% more STIs. But, of course, it takes much more than 11% longer to find them. In this case, 69 work weeks were needed instead of the 60 that the project leader predicted on the basis of the 90,000 line system.

In order to negate the effect of an 11% increase in system size, the entire 100,000 line system would have had to have been written with no more than 7F/KLOC. This was an unlikely improvement over YES’s normal experience, and showed it would have had to make significant changes in its development process to compensate for increased problem demands. It discovered that the late-added 10K actually showed a discovered fault rate of 17F/KLOC, almost double the usual experience. This was the first time YES had an actual measure of how much poorer its code was when written quickly, under pressure.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 14


The Linear Fallacy

by Tony in QSM1

For many years, analysts had seriously overestimated oil recovery from regions, based on early drilling success. They had hypothesized all sorts of explanations for the failure of their modules, but Root and Drew finally demonstrated that the failure of the models could be explained by a selection fallacy: “First, most of the oil and gas discovered in a region is contained in a few large fields; and second, most of the large fields are discovered early in the exploration of the region.”

Obviously, if you drill holes at random, you’re more likely to hit oil somewhere in one of the big fields than in one of the small ones.

The Root-Drew fallacy is committed every day in software development in trying to predict how long testing will take based on early results from testing. The smallest amount of test time is spent on a few easy problems; and second, most of the easy problems are found early in the test cycle. It also explain why so many project as “ninety-nine percent complete” for month after month.

— Jerry Weinberg, Quality

Software Management Vol 1, Chapter 13


The Best and Worst Programmers

by Tony in QSM1

A software development manager told me that he had a way to measure who were his best programmers and who were his worst. Fascinated, I asked him how he did it. He told me that he observed who was always out asking questions of users and other programmers. I thought this was a terrific measure, and I discussed it with him with great excitement.

After a few minutes, however, I realized that he thought the programmers who spent the most time asking questions were his worst ones. I, on the other hand, thought that they were probably the best programmers in his shop.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 12


Hypodermic Marketing

by Tony in QSM1

In development organizations that sell their products, we often find a marketing function. Marketing is not the customer of the development organization, but a surrogate that represents the customer, sometimes well and sometimes badly. If you satisfy the customers, you don’t really have to satisfy marketing; but if you don’t trust marketing, you have a problem.

We create a marketing function to stand between the customer and the system to reduce the flow of disturbances. “Marketing” in this sense may include a variety of roles, such as developing product requirements, aiding in the installation of new systems, training users, and servicing any problems that arise at the customer’s location.

In return for this reduction of disturbances, however, we put another group of people – the marketing staff – nearer the core of the system, under the skin (“hypo-dermic”) as it were. Because of this position of marketing, their disturbances bypass all other defenses. There may be fewer disturbances, but each one is harder to deal with because they are already “inside”. The effect of these people wandering among the development staff is like a strong medicine wandering inside your body. They act faster, and they act diluted. You may get side effects that are worse than the original disease. That’s why the marketing organization, like any medicine, can so easily stop being a solution, and start becoming a problem.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 11


The Principle of Addition

by Tony in QSM1

Everything you have ever known is stored somewhere in your brain, so you can never eliminate mental models, you can only add to them. That’s why this book is based on the Principle of Addition:

The best way to reduce ineffective behavior is by adding more effective behavior

That’s ultimately the way organizations move from one pattern to another. As they add more effective models, they find them used more and more, and this simply leaves less opportunity for the ineffective ones to be used. Organizations get addicted to certain practices that are harmful in the long run, but relieve their pain in the short run. The more the organizations do them, the worse they feel, and the more they seek the relief of their addictive practices.

If you find an organziationaddicted to some short-sighted intervention, you have to look for what rewards (explicit or implicity) are given for short-run success in this behavior. Then remove those if you can and supplement them with rewards that are tied to long-run success.

— Jerry Weinberg, Quality Software Management Vol 1, Chapter 10