Jerry Weinberg has been for almost 50 years the leader in considering software engineering not just as a technical practice but as a human activity. I’ve read seven of his books and with the exception of people I’ve actually worked with, I’ve learned more about IT from Jerry than from any other person.
He’s recently been diagnosed with what doctors say is a fatal illness. He has a CaringBridge site where he can read messages.
A problem-solving leader’s entire orientation is toward creating an environment in which everyone can be solving problems, making decisions, and implementing those decisions, rather than personally solving problems, making decisions, and implementing those decisions.
[W]hat … meetings are doing is playing out an emotional drama–conflict, blaming, flirting, one-upsmanship, random outbursts, anger, and so forth….the soap-opera aspects of meetings are the most exciting parts of their jobs….
Indeed, these people are often upset if I show them how to conduct well-run meetings, because I’ve taken all the joy out of their lives.
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.
Jerry Weinberg’s top three reasons for software projects going over budget or failing to meet their original requirements:
The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.
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).
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.
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:
Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.
We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . .
All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development.”
In his book, Agile and Iterative Development, [Craig] Larman has well documented the history of the many disasters introduced by accident when the Department of Defense standardized on a non-iterative method that was unproven on large projects. It was essentially a blunder by a consultant who had little experience with real software development.
The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations.
