Jerry Weinberg has suggested that “it works” may mean “We haven’t tried very hard to make it fail, and we haven’t been running it very long or under very diverse conditions, but so far we haven’t seen any failures, though we haven’t been looking too closely, either.” In this pessimistic view, you have to be on guard for people who say it works without checking even once to see if it could work.

 

“No user would do that” really means “No user I can think of, who I like, would do that on purpose.”

Who aren’t you thinking of?

Who don’t you like who might really use this product? What might good users do by accident?

 

In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards. . . . Instead of thinking pass vs. fail, consider thinking problem vs. no problem.

— James Bach

Jerry Weinberg’s top three reasons for software projects going over budget or failing to meet their original requirements:

1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.

2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).

3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project’s success is determined by the leaders’ ability to manage themselves emotionally.

Leaders who don’t care about people don’t have anyone to lead, unless their followers don’t have a choice.

— Jerry Weinberg, Becoming a Technical Leader

I’m rereading parts of The Psychology of Computer Programming and I notice that several of Weinberg’s “food for thought” questions at the end of each chapter would be good questions to pose to a hiring manager:

1. How long have you been in charge of your present group? How many of the original people remain? How many people have left and what were the reasons for their departure? What sort of provisions do you make for this kind of turnover?
2. Describe the sequence of work planned for your current project. Is the actual work proceeding according to the original plan? Do you expect it to continue in this manner?
3. How close is your progress reporting scheme to the reality of the work that goes on? What checks do you have to find out if it corresponds to reality?
4. What is your impression of what motivates your staff? Is it the same for all of them?

This is Weinberg’s Zeroth Law of Software: If the software doesn’t have to work, you can always meet any other requirement.

— Gerald M. Weinberg, Quality Software Management, Volume 1: Systems Thinking

The last two development projects I’ve worked on had one thing in common: We charged the client a pile of money and delivered basically nothing of any utility.

Another way to look at it: We met all the requirements by delivering software that didn’t work.

In one case, the client was big enough and flush enough to be able to weather a multi-million dollar misadventure and remain solvent.

In the other case, the client was a dot-com startup, wasn’t able to take the pounding, and had to go out of business.

That summarizes my recent contribution to the software industry.

Mediocrity is Seductive

The quality of the work being done at our shop — and at many other shops — is very poor, our project success rate is approximately 0.0 percent, the tools and techniques we’re using have been proven not to work, at least in the way that we’re using them, and yet any suggestion that we might want to try something different, with an eye towards improvement, is met with incredible resistance.

Why is that?

Well, I have to admit that even I feel a certain comfort level from the abysmally low expectations we’ve established for ourselves, both internally and on the part of clients.

The fact that no one really expects the software to actually work is, as Weinberg’s Law predicts, an incredible simplifying factor.

Clearly we could do better, but there might be some actual effort involved — and since no one expects better anyway, why bother?

Thus spoke The Programmer.

Related Links

• High Failure Rates on the Web
  In what sense can something be said to “work” if it fails 35 percent of the time?

An old joke

A man bought a new suit from Levine the Tailor, but when he tried it on, it didn’t fit him at all.

The jacket was too big in back, one sleeve was too long, one pant leg was too short, but Levine showed him that by hunching his back, leaning to one side, stretching out his right arm, and pulling up his leg at the hip, the suit could be made to fit, although he ended up limping rather badly.

As he hobbled down the street, he was stopped by a stranger, who said, “Pardon me, but where did you get that suit?”

“Levine,” he replied. “Just up the street.”

“Why, I believe I’ll go to Levine for my new suit,” the stranger said. “He must be a genius to fit a cripple like you!”¹

From a consulting company’s marketing literature:

We approach enterprise-class technology implementations with a simple philosophy:

• Use COTS whenever possible
• Leverage existing technology whenever possible
• When custom software is required, make it as modular and generic as possible

If I’m a potential client looking at that, I have a couple of concerns:

1. Web development was a lot faster and cheaper a few years ago before we started building around all these COTS products; and

2. Your philosophy seems to indicate that you lack the confidence, or the initiative, or the ability — or all three — to come in and model my business processes and build a system around them. Instead, you’ll bring me a generic, one-size-fits-all model and force-fit it to my business, or more likely, force-fit my business processes to the model. And at these prices, I don’t like it. I see the advantages to you of generic solutions, but I don’t see the advantage to me.

Thus spoke The Programmer.

1. Gerald M. Weinberg, The Secrets of Consulting [back]