Gerald M. Weinberg Quotes

Jane easily shifts among activities — testing for discovery, pinpointing, locating, determining significance, repairing, troubleshooting, and testing to learn. As long as she continues to serve her customers, it doesn't really matter which task she performs at any given time.

Survival requires that we learn to laugh things off and start over

• Do you think the outcome of testing will make your decisions for you? Business decisions cannot be made from a purely technical perspective. Certainly use information from testing to color your business decisions, but don't substitute testing for business decisions. For example, it can be a good business decision to ship a system that fails one or more tests. Conversely, it can be a bad business decision to ship a system that passes all your tests. Management has to consider other factors in addition to test results. • Conversely, is there any possible test outcome that would make you change your decisions? If not, why would you want to know the outcome, let alone pay for it?

When you're not terribly smart, it helps to be a good listener.

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

A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct — even if this means the oversight of errors which are monstrous to another eye. All programmers are familiar with the symptoms of this dissonance resolution — -in others, of course.

admiring remarks of my team as I track down the latest obscure but in the Project Mercury Monitor System.

The shortsighted or insecure team leader may feel that the best way to please management is to promise them whatever they ask. But, ultimately, what the management wants is kept promises, and these can only be obtained if the team leader can win team acceptance of the promises as their goals. What the team leader must learn is that Managers — no matter how hard they press for promises — really want results. Results will be far more easily obtained if they are obtained in the pursuit of goals set with full team participation.

People have lost sight of the original intention of COBOL’s designers. To quote one of them, Jean Sammet: The users for whom COBOL was designed were actually two subclasses of those people concerned with business data processing problems. One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anybody who had not written the program initially. In other words, the readability of COBOL programs would provide documentation to all who might wish to examine the programs, including the supervisory or management personnel. Little attempt was made to cater to professional programmers…

I’m reminded of the story of the village idiot whose antique watch stopped running. He pried it open and found a dead cockroach inside. “No wonder it doesn’t work,” he said, “the manager is dead.

In many programming situations, the primary working unit is a team, not an individual.

the more adapted an organism was to present conditions, the less adaptable it tended to be to unknown future conditions.

Within IBM at that time, growing a beard without getting fired was an indisputable mark of technical genius.

Leadership is familiar, but not well understood.

Another essential personality factor in programming is at least a small dose of humility. Without humility, a programmer is foredoomed to the classic pattern of Greek drama: success leading to overconfidence (hubris) leading to blind self-destruction. Sophocles himself could not frame a better plot (to reveal the inadequacy of our powers) than that of the programmer learning a few simple techniques, feeling that he is an expert, and then being crushed by the irresistible power of the computer (the Deus ex Machina).