Software Engineering for Usability

8. People more important than process

• 8.1 Placement of HF specialists
• 8.2 Get the best people
• 8.3 Quality (Usability) is Free
• 8.4 Education of programmers in HCI

"Far too much is written about processes and methods for developing software; far too little about the care and feeding of the minds that actually write that software." "... it pays to work on the skills of collaboration, thinking, and software development methods, and to provide an environment where those skills can be effectively applied. This is the so-called `peopleware' approach ..." (Bach 1995)

"The major problems of our work are not so much technological as sociological in nature. Most managers are willing to concede the idea that they've got more people worries than technical worries. But they seldom manage that way." ... "If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, 'The light is better there'." (DeMarco and Lister 1987)

Edward Yourdon says:

"... attention to peopleware issues can literally cause 10-fold productivity improvements, while investments in CASE, methodologies, or other technologies rarely cause more than a 30-40 percent improvement." (Yourdon 1993)

He lists the following as peopleware efforts:

* Hiring the best people

* Ongoing training

* Motivating people for performance

* Manage people so as to make them work for the goals of the corporation

Adequate working environment ("rather than the pigsties in which most software engineers find themselves squatting for 10 hours a day") (Yourdon 1993)

* Emphasis on creating effective teams

(DeMarco and Lister 1987) criticize the dumbing-down effect of an imposed Methodology:

"A Methodology is a general systems theory of how a whole class of thought-intensive work ought to be conducted. It comes in the form of a fat book that specifies in detail exactly what steps to take at any time, regardless of who's doing the work, regardless of where or when. The people who write the Methodology are smart. The people who carry it out can be dumb. ... The Methodology makes all the decisions, the people make none. The organization becomes entirely deterministic."

They point out that such an organization cannot deal with situations not previously planned for, that the workers get demoralized, and that often such imposed Methodologies get ignored or, what is worse, experience "malicious compliance" (where the workers do what is prescribed even though it is sometimes obviously counter-productive).

"There is a big difference between Methodology and methodology. Small m methodology is a basic approach one takes to getting a job done. It doesn't reside in a fat book, but rather inside the heads of the people carrying out the work." (DeMarco and Lister 1987)

In the context of user interface development, this means that the education/training of developers is vitally important -- they need to internalize HCI concerns. It is also interesting to note that in a study of 9 designers in Danish companies where Structured Analysis methodology was being used, it was found that designers do not follow the procedures prescribed by the method -- instead they take shortcuts, relying on their intimate knowledge of the existing software and how it is implemented. (Bansler and B¿dker 1993)

8.1 Placement of HF specialists

A study at IBM (Bias and Reitmeyer 1995) investigated the "optimal organization placement of human factors professionals in software development organizations". The authors discuss the advantages and disadvantages of centralized versus integrated (`mainstreamed') versus hybrid mixture and concluded that a hybrid model works best in many situations since human factors experts outside of the product team can bring more objectivity to product evaluation .

Different parts of a company often don't communicate effectively -- in fact there is often inter-departmental rivalry that actively discourages communication. In this situation, an interface designer from "outside" can act as an information collector to get the whole picture which is unavailable to people in the midst of the politics.

(Brooks 1995) recommended that the software architects should be made available for telephone/email consultation on questions of interpretation. This would seem to apply equally strongly to the user interface designers: implementers of a user interface design should be encouraged - if not required ! - to consult with the designer during implementation (in the case where the designer is not already part of the day-to-day team). And Brooks' recommendation that these interpretative interventions should be logged for future use by others on the team also applies.

The need for uninterrupted design time is described by Bruce Tognazzini:

"If I'm expected to go beyond the kinds of surface changes I can accomplish in a fast review, I have to drown myself in the project. I have to explore existing applications and their interfaces. I have to meet with a range of the people who will use the product and internalize the way they look at their work and at their life. I want to absorb their very essence, so that when I sit down to selfishly design an interface that will work for me (which is the only way I can work), I am designing an interface that will work for them as well." (Tognazzini 1995)

He mentions the common problem that skilled designers are often spread too thin - so that they cannot achieve this necessary immersion.

8.2 Get the best people

For general programming, the best people are at least 10 times better (faster, fewer bugs, more efficient programs) than the worst. (Yourdon 1993) This is likely to also be true -- if not more so -- for user interface design and programming.

(Lewis and Rieman 1994) give the following advice on hiring HCI people:

"... the people you want are interested in the richness and detail of human life. They like to know what people do and how they do it, and what problems they encounter. They're more excited about seeing their system help somebody do real work than about the logic of their design. In our opinion this trait is more important than technical skills, whether in computing or psychology, because it's harder to acquire."

It is important to prevent a high turnover of your staff. No matter how well you have documented things, a large part of the useful design memory of your projects resides in the heads of your designers. But of course, eventually some people will leave the organization. Yourdon emphasizes that "exit interviews" are very important for getting candid opinions on organizational problems. (Yourdon 1993)

8.3 Quality (Usability) is Free

Some managers will likely feel that their project can't afford so much time spent on usability. They will worry that the iterations of prototypes will be never ending, with those HCI people trying to get everything perfect. There are two answers to this. First of all, there should be measurable usability objectives set as part of the project plan. And secondly, these managers should consider the longer-term effect of quality work on the self-esteem (and hence productivity) of their developers. (DeMarco and Lister 1987) has a hypothetical manager saying:

"Some of my folks would tinker forever with a task, all in the name of 'Quality'. But the market doesn't give a damn about that much quality -- it's screaming for the product to be delivered yesterday...". DeMarco and Lister agree: "People may talk in glowing terms about quality or complain bitterly about its absence, but when it comes time to pay the price for quality, their true values become apparent." and continue on to say that "the client's perceived needs for quality in the product are often not as great as those of the builder." but that letting the builders of a product (the software developers) apply their own judgment as to when the software is ready for release will result in higher productivity in the long run. "Quality, far beyond that required by the end user, is a means to higher productivity." (DeMarco and Lister 1987) The studies that document this are: (Crosby 1979; Jones 1994)

When deciding on how user interface development is going to be integrated into the wider development process, managers should keep in mind the "Hawthorne Effect" (Parsons 1974). DeMarco and Lister state this as: "people perform better when they're trying something new" -- because of this, they recommend that each project should vary the techniques used just for the sake of variety. (DeMarco and Lister 1987)

8.4 Education of programmers in HCI

(Strong 1994) points out the lack of HCI knowledge in development teams and says:

"... it is also important for companies, unions, and other applied institutions to consider appropriate workshops, tutorials, apprenticeships, practica, and other on-the-job training experiences for those skills that are, for whatever reasons, not learned in academic programs."

(Karat and Dayton 1995) describe what they think are the important HCI ideas and skills that are needed by developers in order that they can do a good job of designing interfaces. They recommend apprenticeship with an experienced user interface designer as the best way for a programmer to learn HCI on the job. Another idea is to establish several "usability advocates" within the company. They describe 3 day user interface design workshops in which the project team works with end-users in learning and using HCI techniques to do the design of part of the real problem they are involved in. and conclude that this is a successful method of training developers.