It may look like a crisis, but it’s only the end of an illusion. — Jerry Weinberg
EppsNet Archive: Jerry Weinberg
The Buffalo Bridle
“Well, if you’re going to control buffalo, you got to know two things, and only two things: First is, “You can make buffalo go anywhere, just so long as they want to go there. “And second, “You can keep buffalo out of anywhere, just so long as they don’t want to go there. — Gerald M. Weinberg, The Secrets of Consulting Read more →
No difference plus no difference plus no difference plus … eventually equals a clear difference. — Jerry Weinberg
The Titanic Effect
The thought that disaster is impossible often leads to an unthinkable disaster. — Gerald M. Weinberg, The Secrets of Consulting Read more →
Whatever the Client is Doing, Advise Something Else
People who are close to a problem tend to keep repeating what didn’t work the first time. If it did work, they wouldn’t have called in a consultant. — Gerald M. Weinberg, The Secrets of Consulting Read more →
Make sure they pay you enough so they’ll do what you say. — Jerry Weinberg
It’s Always a People Problem
Even when it’s “really” a technical problem, it can always be traced back to management action or inaction. Even so, the experienced consultant will resist pointing out that it was management who hired all the technical people and is responsible for their development. At the same time, the consultant will look for the people who should have prevented this problem, or dealt with it when it arose. — Gerald M. Weinberg, The Secrets of Consulting Read more →
Jerry Weinberg
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. Read more →
Organic Organizing
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. — Gerald M. Weinberg, Becoming a Technical Leader Read more →
Why (Some) People Love Meetings
[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. — Gerald M. Weinberg, The Secrets of Consulting: Why We Love and Hate Meetings Read more →
James Bach on Software Testing
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. . . .… Read more →
Three Reasons for Software Project Failure
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. Read more →
Leaders Who Don’t Care About People
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 Read more →
Four Questions to Ask a Hiring Manager
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: 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? 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? 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? What is your impression of what motivates your staff? Is it the same… Read more →
The Waterfall Approach Persists as an Urban Myth
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. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” 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… Read more →