Gerald M. Weinberg

Programmers do not ordinarily work in isolation. Although an individual programmer may find herself assigned the task of writing a program, even then she has other programmers to whom she may turn for help — and who, at the same time, may be turning to her.

In this business, it takes all the running you can do just to stay in the same place.

If you don't have questions about a product's risks, then there's no reason to test. If you have at least one such question, then ask: Will these tests cost more to execute than their answers will be worth?

By making the time tradeoff explicit and by indicating a willingness to contribute time now, I make it clear that it is a problem of limited time, not a problem of limited respect for the other person.

each program has an appropriate level of care and sophistication dependent on the uses to which it will be put. Working above that level is, in a way, even less professional than working below it. If we are to know whether an individual programmer is doing a good job, we shall have to know whether or not he is working on the proper level for his problem.

Repeatedly curing a system that can cure itself will eventually create a system that can't.

Programs, like any other human-made objects, are designed — or should be designed — with a definite lifespan and scope of application in mind. Like the “Deacon’s Masterpiece,” which was “built in such a logical way it ran a hundred years to the day,” a program should have neither over-designed or under-designed parts. Yet it is an occupational disease of programmers to spend more time on those program parts that present, for some reason, the most intellectual challenge rather than on those that require the most work.

Since nobody's perfect, we need resistance to test our ideas.

One typical computing example of social fixation is the adoption of one programming language by an installation. Once the language has been adopted, a new language has more difficulty making an entry, because with most of the people using the old language, advantages accrue to following the beaten path.

When we do read code, we find that some of it gets written because of machine limitations, some because of language limitations, some because of programmer limitations, some because of historical accidents, and some because of specifications — both essential and inessential.

*No matter how strange it may look, most people are actually trying to be helpful.* That

There are many technical workers who enjoy wandering so much that, like Alice in Wonderland, they don’t much care where they go, so long as they get somewhere.

Or, suppose you want to motivate your managers to ship products on time, so you conspicuously promote each manager whose product goes out the door on schedule. All goes as planned until the situation arises in which one of your managers has a project where the testers are reporting numerous problems. Because managers who have shipped products on time have been promoted, this manager thinks, I want that promotion so I need to ship this on time, but those bug reports are getting in the way. I know what I'll do! I'll put the testers on another project until the developers have a chance to catch up.

In the army — old-fashioned style — every foot-soldier was considered interchangeable with every other. The hierarchical organization, then, was conceived as the structure that could give the fastest and most direct coordination between these interchangeable parts. But a programming project is not a battle, regardless of appearances. There is no need for quite the speed of communication which is necessary under field conditions, nor are the things to be communicated so simple that they can be barked over a two-way radio with shells bursting in the background. What is needed in a programming project is slow, careful communication among teams of people doing very different, highly specialized tasks.

Good testing involves balancing the need to mitigate risk against the risk of trying to gather too much information.