When executives code
by Phillip Armour.
Communications of the ACM
Volume 47 , Issue 1 (January 2004)
Pages: 19 - 22
Year of Publication: 2004.
This article is available online through
the ACM digital library (link above).
The author describes conducting an experimental three-day program to teach executives about software. After a day of lectures, excercises, and games, the executives were given the task of building a functioning software system by the end of the day.
They were given a development environment with “wizard” capability
with which, a functioning system that fulfills the basic requirements could have been created in about one to two hours.
What they learned was instructive for them and reading about it is instructive for anyone who has to deal with IT departments, software development, and digital library projects.
On the first day, the network system for the class failed. The author started to fix the problem, then realized that it was not his problem!
“I sympathized with the group, hoped they would be able to solve the problem, and reminded them of their deliverable due at 3:30 p.m. Then I left the room.”
An angry VP confronted the instructor:
“How can you expect us to do this job, if you don’t provide us with the necessary resources! We don’t know anything about network maintenance!” He ranted for perhaps two minutes before he listened to what he was saying. He stopped, thought a moment and then carefully observed, to himself more than to me, “…so, if we don’t have dedicated network resources available to projects, each project will have to learn network maintenance instead of learning what the customer needs.” An Archimedean moment.
The instructor toyed with unplugging the server at 3:15 to see if anyone had thought to back up their work, force them to upgrade their operating system halfway through the day, or change the core requirements once or twice during the day. But he discovered there was no need to add obstacles to their work as obstacles (like the network crash) emerged serendipitously.
At various times we had overwriting of peoples’ programs, lack of documentation or coordination, accidental deletion of code and Web pages, contradictory development, and version control problems. It was never necessary to introduce artificial snafusÑexcept interruptions.
Three times in the day the instructor made the class attend meetings.
By the third disruption, they were starting to understand, and were also starting to get quite angry with me. The status reports I requested at each interruption point were equally unpopular, and generally elicited impatient comments such as “we’re doing OK,” “we can’t exactly say how much longer it will take…,” “…we haven’t been collecting metrics because we’re too busy doing the work…,” and, of course, “…we’re about 90% complete.”
In the end, no team produced a system that actually worked and the students’ final presentations were punctuated with comments such as “…this is all we were able to do in the time we had…,” “…we planned to add a menu here, but we didn’t get around to it…,” and my favorite: “uh… it’s not supposed to do that… .”
As the executives realized they had spent the day doing what they often accuse developers of doing: playing, working on the “cool” stuff rather than the functional stuff, and hacking rather than carefully crafting, they started to understand the lure of the learning and creativity inherent in building systems. As senior executives, they knew a lot about the business, so by focusing on their role as users and specifiers of the system they would mostly rehash what they already knew, albeit in a different context.
This article is an excellent 5 minute overview of what it like for programmers at work in the real world.
