The traditional view of the workplace is that the team is doing a job, and the individual is a part of this effort. But as mappers we can try looking at things in all sorts of odd ways, to see if they are informative. We can draw a system boundary around the programming team and notice that it does nothing that an individual programmer couldn't do. Activities such as requirement elicitation, design, implementation, test, management, review, build, archive and configuration management must all be performed by a single programmer doing even a small job. So we can see software engineering activities as the distribution of what a single individual could be doing quite effectively and responsibly in potter mode in his or her study!
We distribute programming for the same reasons that we distribute any kind of processing: availability, parallelism, and specialization.
This way of looking at things brings insights. We must select the divisions between tasks intelligently. Sometimes we can get benefits from putting two tasks with one person, where we need not be concerned if they merge. For example, many organizations have a general practice of separating the identification of software requirements and architecture, but when they are following Booch style object modelling methodology, they take his advice and merge these tasks. When we separate the skills of design and test, we can actually get added benefits from the situation, by controlling communication between the disciplines so that the test engineer's thinking is not compromised by the designer's. There was a project manager who was very much a packer. He didn't have a clear understanding of what he was doing and why and had been led by the absence of any positive model of his job into thinking that a key objective was preventing this communication. The testers didn't know how to set up the conditions for the components they were to test, and the designers weren't allowed to tell them. Acrimonious arguments continued for days. These things really happen when we lose sight of the big picture.
We must make sure that the communication between distributed tasks is efficient, and that means that we must agree both a protocol and bear each others' needs in mind. Anything you'd need in your mind when you have completed one task and are about to embark on another, your colleague needs in his or hers. Your output will be no help to anyone if it doesn't tell your colleague what they will need to do the next bit. We need to use our own ability to perform each others' jobs, no matter how naively, to monitor our own performance.
The final insight we need to raise at this point is that the black box of an individual programmer still exists in the team. The flow of information is not a linear series of transforms like a car factory, it is a fan-in of issues to a designer and a fan-out of solutions. The insight of the designer has not yet been distributed. Such an achievement would be a major result in AI.
Copyright (c) Alan G Carter and Colston Sanger 1997
Top comments (0)