Chapter 19: Part and Whole
Aristotle Kenoros was a morning person. If he was going to make an appearance, it was most often the first business of the day. This morning, Mr. T arrived at his office to be told by Mrs. Beerzig that Morovia’s First Programmer was waiting for him inside. Mr. T. found him sitting on the desk, staring up at a matrix of letters he had drawn on the whiteboard.
For the purposes of this grade, I did not consider so much the quality of their designs as whether they had produced a design at all. If you have a low-level modular design that serves the function of a blue print that is, it establishes what all the coded modules will be and what interfaces there will be among them then Kenoros gives you an A.
All the small teams got A’s and B’s. The big teams got all the F’s. and the Oracle’s concept of Last Minute Implementation is going to be impossible without a good design. In fact, they are not going to be doing Last Minute Implementation. The six A Teams started coding long ago. I had no success persuading them to defer implementation. all the B and C Teams are trying out the Oracle’s approach. They are all trying to push back implementation, and to do as much verification work as pos- sible before a single line of code is written. Some of them are trying rigorously to defer coding until the last sixth of the project.
Kenoros has a teory that the teams were too big. During the whole time that design should have been going on, they had too many people to involve in that activity. Design is a job for a small group. they can put three or four or maybe five people around a white board and they can do design together. Mr. T didn´t understand what was happening and say “You can put three or four or five to work on design and put the rest to work on something else.”
The design step is the critical act of dividing the whole into pieces. Once you’ve done that, then you have good opportunity to allocate these pieces to people to work on sep- arately. But before you’ve done it, you don’t have pieces. What you’ve got is a whole.
Design Process in Software Engineering is a very important step that precedes building or implementing the product. For example, consider constructing a building. It is unimaginable that builders go straight to the field and start the construction before detailed designs are established by engineers. In fact, constructing a building without designing it beforehand would be dangerous and the building may have serious issues that could put people’s lives in danger.
Mr. T was still not convinced. “If it’s true, what you say, then most projects are effectively overstaffed during the period when design should be done. So, most projects wouldn’t get any real design done.”
Mr. T rehashed the notion that early overstaffing effectively precludes sensible design. To the extent that Kenoros was right about this, the ramifications went far beyond Aidrivoli. They suggested that the entire software industry might be sub optimized in this way, addicted to early staff buildup and thus making a sham of the key internal design activity.
When work is divided over a large staff prior t o completion of design, the interfaces among people and among work groups are not minimized. This leads to increased interdependence, meeting time, rework, and prustration.