Ullman, Ellen. Close to the Machine: Technophilia and Its Discontents. San Francisco: City Lights Books, 1997.

Ullman managed a project to developed a system for a department serving individuals with AIDS. The director of the department told Ullman that she wanted cross-checks on funding sources, billings and contract compliance. She tried to convince the director that this was a bad idea, since "the machine cannot keep rounded edges; that its dumb, declarative nature could not comprehend the small, chaotic accommodations to reality which kept human systems running." The director was quite insistent, however, and "the system became the justification for the system. We collected data, therefore it had to be 'good' data. And since we could link one database to another, since it was possible to cross-check data here with data there, well, we should link them. And what was designed to store patients' information as a service for them, had somehow become the property of the 'people paying for this system'—an agency of the federal government."

Ullman explains that the director "succumbed to the fever of the system. As a product manager once told me, 'I've never seen anyone with two systems who didn't want us to hook them together.'" An earlier customer wanted her to set up a system that would monitor the keystrokes of his employees, since it would be so easy to do. Such experiences made Ullman increasingly aware of the division between building code and the social reality in which they are used. For a manager of software development projects, this awareness is a mixed blessing.

"It was easier when I didn't have to think about the real-world effect of my work." Through an account of her own work and life experiences, Ullman provides an interesting window into the mindset of software engineering. She describes the way programmers thrive on "disappearing into the code" and they ways in which this can often create a significant divide between those building software and those who market, manage and use it. This is partially due to misguided but commonly adopted development methodologies, which usually do not involve the users until the software is half-written. It is also due to much more fundamental characteristics about how an engineer must think in order to build reliable, efficient and stable software. In the conceptual realm of programming — what Ullman calls "that place" and "the code zone" — "thought is telegraphic and exquisitely precise."

Such thinking is an asset from a technological viewpoint, but serious problems arise when "human needs must cross the line into code. They must pass through this semipermeable membrane where urgency, fear, and hope are filtered out, and only reason travels across." Human activity is based on innumerable subtle attributes, each of which "must be denatured in its crossing to the machine, or else the system will die." System requirements that seem quite simple and obvious to a business manager are often far too imprecise when translated into code. Since computers lack the human ability to "leap over small misunderstandings," minute details must be specified explicitly and consistently.

"As the months of coding go on, the irregularities of human thinking start to emerge." It is then up to the programmer to resolve the vagueness and ambiguities. They can and often do ask for clarification from others (analysts, managers, end users), but the answers to specific implementation issues are often completely absent, vague, ambiguous or contradictory. Unrealistic deadlines exert extreme pressure to release a working system and are often not changed when they should be. Ultimately, the programmer must "retreat into some private interior space, closer to the machine, where things can be accomplished."


Everyone involved in the development and implementation of computer systems should be aware of these issues. As end users and those investing in new systems, we should remain aware of the following:

  • No set of requirements documents or system specifications will be logically complete from a software engineering perspective. Whenever a process is implemented through a computer system, those developing the system must use their own discretion in resolving many of the details.
  • Programmers and end users use different language and think in different ways. Conversations will be much easier after recognizing this.
  • Though getting "close to the machine" is essential for software development, it is important not to conflate the technologically possible with the desirable. Some types of data simply should not be collected and many tasks should not be implemented through ICTs.

» Next: Wartella, Ellen, Barbara O'Keefe, and Ronda Scantlin