JoAnn Hackos, PhD
Phillip Armour, VP of Corvus International, had a brilliant and cruel idea. In conducting a three-day workshop to teach executives about software, he gave them the task of creating software themselves—just to see what it felt like. The first day of the course was predictable enough, consisting of a lecture about the software-development process. Attendees included executives from marketing, finance, manufacturing, and even a corporate counsel. Their goal was to learn about the software-development activities in companies that are not in the software business or at least don’t see themselves that way.
In the second day of the course came the surprise. Armour divided the attendees into teams and told them their task was to create an interactive Web site that would be valuable to people like them, managers who needed to understand software development. They were supposed to complete the process from design through planning, development, and testing by 3:30 that afternoon. Most of the people had never done anything like this before. Some had rarely used a computer except for word processing; a few couldn’t type. Armour gave them a strict deadline (“in advance of any detailed requirements, of course”). (pg 20).
Software developers had suggested to Armour that he plan for glitches. Some wanted him to announce a software upgrade in the middle of the day; others suggested changes to the requirement midway; one wanted to change team members arbitrarily. None of the planned glitches was necessary. Real problems happened all by themselves. Team members overwrote each other’s files, accidentally deleted entire finished Web pages, and had problems with version control.
When one team first turned on their computer, they got a network diagnostic error. Rather than following his first impulse to fix the problem, Armour simply reminded them of their deadline, hoped they’d be able to solve the problem, and left the room. An angry marketing VP followed him into the hall, complaining vigorously. “How do you expect us do to this job, if you don’t provide us with the necessary resources! We don’t know anything about network maintenance!” As Armour listened, the VP suddenly realized what he was saying. If people don’t have the resources backing them up, they have to spend time learning maintenance or something else, rather than attending to customer requirements.
Armour even held hourly meetings, pulling everyone away from their jobs to ask for status reports and estimates of completion.
As one might expect, the teams had a great time creating their Web sites, adding lots of little animated GIFs from a library they were given. They became quite attached to their solutions, even though not one of the programs they created actually worked. They quickly forgot about process, planning, and testing, succumbing to the fun of creating and hacking.
In the course of the workshop, they discovered what really motivated software developers and what made it so difficult to succeed. They learned that they couldn’t stifle the learning and creativity involved in the job under a suffocating blanket of controls. They had to create the right atmosphere for software development to succeed, appropriately channeled to meeting the needs of users.
Wouldn’t it be fun to do the same with technical writing? Could we get the executives to agree to a workshop in which they actually had to produce a finished manual given all the constraints under which one typically works? Probably not. But the idea is enticing.
Read the article, “When Executives Code,” in Communications of the ACM, January 2004/Vol. 47, No. 1, pages 19-22.