Book Commentaries from Reflections

Bad Software
The Psychology of Computer Programming, Silver Anniversary edition
Peopleware, Productive Projects and Teams
Mastering the Requirements Process

From Vol.2, No. 1:

Book Commentary:

by Cem Kaner and David Pels

You bought some software. You unwrap the disk, pop it in the drive, and install it. It doesn't quite do what you want it to do. Maybe it destroys a whole set of files. Worse, maybe it even erases your hard drive. What should you do?

You should read Bad Software, before you do anything. Cem Kaner and David Pels wrote a readable, understandable, helpful book to help you solve your bad software problems. Kaner and Pels walk you through a set of activities designed to help you either solve your problem or get some form of satisfaction from the software publisher.

The book addresses what to do before you call the software publisher, knowing what to ask for, and how to make the call. If you don't get satisfaction from the publisher, the book then discusses some legal possibilities: dealing with consumer protection agencies, lawsuits and lawyers, and small claims court.

If you work for a software publisher-- you create software that is sold commercially to more than one unique customer-read the section entitled "Software Quality and the Law". I was quite surprised to find out that what the marketing people say may be a real warranty of how the product works. I was even more surprised to discover that if the documentation does not reflect the product, the documentation is the representation of what the product should do.

This has serious implications for software publishing organizations. If your consumers know that the documentation is the definition of what the product is supposed to do, and they want what the documentation promises, you may have to provide it free. An even better reason to be very clear about what you're putting into a given product release. After all, if you're intentionally too vague, your customers might assume you did want to sell them the software equivalent of the kitchen sink.

The appendix has very timely information about Article 2B, proposed revisions to the Uniform Commercial Code. At the time this newsletter went to press, the proposed Article 2B would allow publishers to:

Limit your use rights, far beyond what other mass-market publishers, such as book publishers, can do. For example, 2B will make it easier for publishers to block customers from reverse engineering their products, something that Kaner says manufacturers of no other type of mass market product can do. We often reverse engineer software to make our products compatible with competitors, or to work around other products' defects. 2B will help a large publisher block a small competitor from achieving compatibility.
Prevent you from seeing the sales (or license) contract until after you've bought the product. According to Kaner, this ability to hide terms like the length and scope of warranty and the cost of technical support allows publishers to avoid competing on quality-related promises. It also encourages harsh contracting because publishers can hide the bad news until after the sale is complete.

Article 2B will encourage publishers to produce "not quite bad enough" software. Kaner says: "This bill helps larger publishers to avoid or limit competition based on quality and customer satisfaction. It helps them sneak harsh terms into their sales contracts, to an extent not allowed in the rest of the mass market. [...] This is a short sighted bill, favored by Dilbert's boss's lawyers. As software developers, we have the knowledge and the credibility to make this bill go away, and we should."

Bad Software is informative and entertaining. There are a number of examples of how to work with a publisher's technical support staff, and how they should work with you. You can use these tips no matter what your level of expertise.

Kaner supports the book with a web site: http://www.badsoftware.com. The publisher, Wiley also has a web site: http://www.wiley.com/compbooks.

From Volume 2, Number 2:

Book Commentary:

The Psychology of Computer Programming, Silver Anniversary edition

by Gerald M. Weinberg

Egoless programming. Twenty-five years ago, Jerry Weinberg published The Psychology of Computer Programming. I discovered the book in 1977, and decided I wanted to work as an egoless software engineer, not as a radio disk jockey.

Egoless programming occurs when a technical peer group uses frequent and often peer reviews to find defects in software under development. The objective is for everyone to find defects, including the author, not to prove the work product has no defects. People exchange work products to review, with the expectation that as authors, they will produce errors, and as reviewers, they will find errors. Everyone ends up learning from their own mistakes and other people's mistakes. That's why it's called egoless programming. My ego is not tied to my "perfect" or "imperfect" work product. My ego is only tied to my attempts to do the best job I know how, and to learn from my mistakes, not the initial result of my work.

This is just one of the ideas still promoted in Weinberg's silver anniversary edition. The book retains the same structure as the original edition:

Programming as Human Performance
Programming as a Social Activity
Programming as an Individual Activity
Programming Tools

Each chapter has comments at the end, living up to his promise in the preface: "I would not try to hide my errors, for they may be the source of the most learning for my readers. I have left the original text as it was-antiques and all-for your illumination, and have simply added some "wisdom of hindsight" remarks whenever the spirit moved me."

I especially enjoyed comments on "Chapter 3: How can we Study Programming?" Weinberg says, "Managers who pay attention to people get good results. Many managers (especially those who were once programmers) want their people to behave like modules of code. These managers think people should function as little black boxes that tasks are fed into and work comes out of, with no observation necessary, and especially no interaction." Met any managers like that recently?

I also enjoyed the comments on "Chapter 13: Other Programming Tools". Weinberg says in his comments "Well, actually, I don't miss cards too much (and I miss paper tape even less!), but I'm enough of a reprobate to yearn for some of the forced delays-delays that gave me time to think about what I was doing. Whatever the future of programming may bring, I firmly believe it will still reward thinking over mindlessness. Should we be doing more to support the programmer who wants time to reflect-and a lot more to support the one who doesn't?"

Sometimes, oldies are goodies. Old books can be even better when they're revised to assess their prophecies and sage advice.

Weinberg has a web site, http://www.geraldmweinberg.com. Dorset House also has a web site, http://www.dorsethouse.com.

From Volume 2, Number 3:

Book Commentary:

Peopleware, Productive Projects and Teams

by Tom DeMarco and Tim Lister

"The ultimate management sin is"

Management sin in the title of a chapter? I wanted to read this book!

DeMarco and Lister have updated their 1987 classic with an additional eight chapters and a few select edits. Peopleware, Productive Projects and Teams, Second edition, still commands attention.

In one of the new chapters, "Teamicide Revisited", DeMarco and Lister address motivational posters and accessories. They say "[These accessories] seem to extol the importance of Quality, Leadership, Creativity, Teamwork, Loyalty and a host of other organizational virtues. But they do so in such simplistic terms as to send an entirely different message: Management here believes that these virtues can be improved with posters rather than by hard work and managerial talent."

The technical people I know certainly agree with DeMarco and Lister-they know that with hard work, and the necessary talent they can achieve quality, leadership, creativity, and so on. Posters and motivational accessories don't provide the hard work, training, or talent.

One of my favorite parts of Peopleware is the chapters on space; especially the chapter entitled "The Furniture Police". Furniture police mandate what furniture you can have, how much space you can have, and whether or not you can hang pictures, plastic flamingos, or blow-up dinosaurs in your workspace. The furniture police decide what you can use as office space and how to use it.

I once worked in an organization where the furniture police were arranging a move to a new building. The good news is that the engineers were finally going to get cubes big enough to work in. However, the furniture police disallowed whiteboards in the cubicles. The furniture police were sure that engineers who wanted to work together needed to go to a conference room to work things out.

That might have been reasonable, but the furniture police had more rules about the conference rooms:

Engineers were restricted to a certain size conference room if only two people were meeting, and
No one could leave anything on the whiteboard after their meeting. The furniture police told the janitorial staff to clean all whiteboards at the end of each day.

The engineers were frustrated, but they were engineers, they could beat this problem. The engineers started to work on paper. They tacked up the papers all over their cubicles and people started standing around in cubes, talking to each other. I saw this, and suggested to the furniture police that they read sections of Peopleware to see the effects of their actions on the organization. Luckily, the furniture police asked for suggestions, so we started to discuss the source of the edict against whiteboards. We were able to diagnose the real problem, noise in the engineers' working environment. We couldn't redesign the space to accommodate how people really worked, to create suites of teams with doors (see the chapter "Bring Back the Door"), but we did get everybody whiteboards that didn't have to be cleaned every night.

What is the ultimate management sin? You'll just have to read the book to find out. It won't be a waste of your time.

From Volume 2, Number 4:

Book Commentary:

Mastering the Requirements Process

by Suzanne Robertson and James Robertson (1999)

"This book is for people who want to discover the requirements before constructing their products" Suzanne and James Robertson, Mastering the Requirements Process, page 1

Suzanne and James Robertson have created a book that supports the activities for specifying requirements, especially complementary to their Volere Requirements Specification Template.

I particularly liked their explanation of their requirements cards, used in initial requirements gathering. One component of the requirements card is fit criteria. Fit criteria are what you evaluate the solution for the requirement against-the measurement of the requirement. Sometimes, it's difficult to describe the performance easily when you define a requirement. Fit criteria can help with this:

Original definition of requirement:

Description: The product shall have virtually no down time.

This description is ambiguous. One way to find out what this requirement adds to the product is to ask "Why?" Some of my clients develop systems that are mission critical-downtime will kill people. If you add fit criteria, the requirement becomes much more precise:

Fit Criterion: Under normal operating circumstances, including installation and upgrades of software, the product shall remain available to at least 25% of the defined number of users. The product shall return to 100% availability within 2 minutes of software installation or upgrade.

This helps reduce the ambiguity, as long as we define "normal operating circumstances". This requirement is still ambiguous, because I haven't defined what the product remaining "available" is. To better define available, I would have to continue to discuss or negotiate the requirement with my customer. Available for the telephone system is probably different than available for a heart monitor or for a weapons system.

The Robertsons also suggest a "Quality Gateway" as a formal technique to test requirements. They suggest a number of issues to consider when setting up your quality gateway, especially the culture in which you work. Does your staff already perform peer reviews? Do you already have formal inspections of project documents? No matter how you set up your quality gateway, test each requirement for: completeness, traceability, consistency, relevancy, correctness, ambiguity, viability, being solution-bound, gold plating, and creep.

Mastering the Requirements Process is full of practical tips and other resources to explore.

Related web sites: Atlantic Systems Guild, Addison Wesley Longman

Book Commentaries from Reflections

ROTHMAN CONSULTING GROUP, INC. Johanna Rothman, President

ROTHMAN CONSULTING GROUP, INC.
Johanna Rothman, President