Yes: Developers are people and face human factors problems

In their classic book Peopleware , Tom DeMarco and Tim Lister report on studies of programmers' productivity relative to the characteristics of their work environment. The results are clear: human factors issues impact programmers greatly.

DeMarco and Lister compared programmers with different levels of performance in terms of programming productivity. The most productive programmers scored high on having a quiet workspace, very high on having the ability to divert their telephone calls, and relatively low on how frequently they were interrupted. In contrast, the least productive programmers scored low on having a quiet workspace, very low on ability to divert telephone calls, and very high on how frequently they were interrupted.

It is clear that interruptions are a major cause of low productivity among programmers. Why? The problem is not the time needed to handle the interruptions themselves, but the time needed to get back into the programming problem. Everybody, no matter what they do, face a reorientation time when they return to their work after an interruption. When you are reading a magazine article and look up to answer a question, it takes you longer to read the next paragraph than if you had been reading continuously.

Programmers have it hard. They have to build up a complex mental model of the programming problem, the state of the different variables, and so on. That's why most people do not make good programmers, but it is also why even the best programmer gets into trouble when he or she is interrupted. Bang! Down falls the carefully constructed mental house of cards. Building the mental state back up to the level required for efficient programming can easily take fifteen minutes. Thus, a two-minute telephone call kills productivity for seventeen minutes or so.

Many other classic findings prove that human factors considerations have supreme importance for developers:

• Fred Brook's classic statement says, "adding more people to a late project will only make it more late" ( The Mythical Man-Month ).
• The dramatic differences between good programmers and bad ones:
• Usually there is a factor of ten or twenty in productivity (often the more productive programmers deliver the best code as well).
• Differences in other fields of human performance are much less: I used to be able to run 100 meters in less than 200% of the world record time.

To improve software engineering in a company, follow this seven-step program:

1. Hire only the best programmers, even if they are more expensive. A good one is worth ten bad ones.
2. Give each programmer a private office with a door that closes (not a cubicle).
3. Have a secretary answer the telephone (or at least use a system that allows calls to be diverted to voice mail without ringing the bell).
4. Ban e-mail (or more realistically, institute a culture where it is OK not to answer your mail for an hour or two if doing heavy coding).
5. Give all programmers a 21-inch monitor or better (bigger screen space leads to better overview of complex data).
6. As soon as 200 dpi monitors start shipping, buy them for your programmers (20% automatic productivity improvement right there for any time spent reading from the screen).
7. Send all your programmers to a touch-typing class.

Sure, good software engineering methodology matters as well, but the human angle is often overlooked.

Back to top

No: Developers are a breed apart

Let us assume that you belong to the intended audience for this developer site. Being one of my intended readers, you are likely to be among the 1% of the population who knows the most about computers. You are also very smart, have extremely good abstract reasoning skills, and you can even write a Boolean query that will work in a search engine.

Before congratulating yourself on scoring so well, let me point out that these facts make you absolutely incompetent when it comes to judging the average user's experience. By definition, most people belong to the 99% who know less about computers than you do. They may still be very smart, but they will often have a different way of thinking that does not work so well with computers. And if you give them a search engine with too many advanced features, they will construct queries that do not retrieve the items they are looking for.

Sorry for harping on the search engines, but one of my pet peeves is the tendency to promote overly elaborate search interfaces with features that can only be used correctly by two classes of people: search engine engineers and librarians who have been through four years of indoctrination. You are almost always better off with a simple search box like that provided by Google. Then provide selected advanced features where appropriate, but don't tempt the user to enter a search page with a million fields that influence each other in ways that require a graduate degree to understand.

Luckily, methods exist that allow developers to bypass their own brilliance and experience their product the way normal people do. In a previous article I discussed the usability lifecycle, and the many different phases where it is recommended to take active steps to collect user data.

For now, let me just mention a single method that has proven very useful: user testing, where you bring in average customers and have them use the software. When they have trouble doing so, the appropriate reaction is not this user must be stupid. The conclusion is: the developers made some mistakes. That's OK, because all experience shows that nobody can design the perfect user interface in the first try. The only real mistake is not to fix the usability problems because you personally think they are easy enough to deal with.

Conclusion: you are not your user.

About the author

Rate this article

Comments

Back to top

Table of contents

• Yes: Developers are people and face human factors problems
• No: Developers are a breed apart
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America