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

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

The manager’s most important task is system design. But it is not the product system that the manager needs to design; it is the system that builds that product: the project. Designing the project means hiring the right people, putting them in the right place, building teams, keeping people’s sprits up, and redesigning when the result is improvable. Great managers don’t even end up steering their projects – they don’t have to. If they’ve succeeded in their design, they have constructed a project that knows how to find its own way.

Tom DeMarco, “Why Does Software Cost So Much”, Essay 5

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

Becoming lean is not a sign of future health, but of present failure. The ultimate way to achieve leanness is downsizing, or, to put it more bluntly, firing lots of people more or less at random. This is what my colleague Ken Orr calls “organizational bulimia.” Downsizing is exactly the opposite of what management has been chartered to achieve. The natural goal for almost any business is upsizing. Downsizing programs are clear admissions of upper management failure. Yet, somehow, it’s never upper management that gets downsized.

Lean and mean means sick and angry. Maybe that’s what many organizations have become, but it’s time to stop pretending that it was ever a desirable goal.

Tom DeMarco, “Why Does Software Cost So Much”, Essay 4

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 bread-and-butter mechanism by which an organization improves is simple enough: People identify best practices that are already working somewhere within the organization and propagate them. This involves no great breakthrough, no new theory. It is basic hygiene. Companies that can do it survive and prosper, and those that can’t don’t.

Less straightforward is propagation of good practice from one organization to another. The problem here is insularity. We are all so buy holding our cards close to the chest that we have trouble learning from each other.

Tom DeMarco, “Why Does Software Cost So Much”, Essay 3

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

The paradox [of software development] is that productivity is often at odds with benefit. Benefit is maximized by taking chances and venturing into new territory. Productivity is improved by familiarity and repetition. When we make software into a production-type activity by “systemetizing” the way we build a certain kind of product, we can get much better at building products of that type. Is this progress? Why do we need so many products that are so much alike? Have we missed an opportunity to build one meta-product from which many instatiations can be generated instead of building the many clones, each one as a separate project? In most cases that is exactly what has happened, and you can see why. Building hundreds of cloned products can result in low risk and high “productivity” for each of the hundreds of projects. Building one meta-project is highly risky and likely to result in far lower productivity, but the total cost of the one risky project may be much lower.

Software is not a production activity. It is a research and development activity, for it is in software research and software development where the only real benefits can be produced.

All the attempts to make software into a production activity are doomed to failure. Companies that “suceed” in this are just creating opportunities for the Mike Hammers of the world to suggest, “Instead of pushing your software factory from CMM level three to level four, why not just close it down? It’s not building anything very useful anyway.” Hammer would call that Business Process Reengineering. I call it Turning the Brain Back to the On Position.

Tom DeMarco, “Why Does Software Cost So Much”, Essay 2

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