by Frederick P. Jones, Jr.
In Chapter 4 of The Mythical Man-Month, the author presents the concept of "conceptual integrity". This means that your system should be of one unifying design principle, and not just a lump of varying functionality. Conceptual integrity is extremely important to ease-of-use, and it is better to leave out some functionality than sacrifice this. It is also important to separate "architecture" of the system from the "implementation" of the parts. The ones that ensure the integrity of the system and it's design are the architects. It should be a small group of people so as to keep the ideas one of track, and they should not bother themselves with how each section might be implemented. If too many of the programmers who are implementing the system get involved in the discussion of the architecture, not enough time is spent on the implementation, which means the system might not be built as efficiently. The programmers still get to have a part in the creative process because they can decide the implementation process and come up with elegant and efficient solutions to the specifications given by the architects.
In Chapter 5, the authors address the issue of the 'second system effect'. Usually, the first system that a group of programmers design is simple, efficient, and functional, because they have made sure they kept conceptual integrity. But, when designing the second system, they try to fix all the mistakes that they made in the first system. The problem with this is that it usually results in feature overload. Even though the new system will be more functional and useful to the users, it is usually an unwieldy monster that feels bloated and inelegant. Another problem is that there might be a lot of focus on a feature that wasn't quite right in the first iteration, even though that feature is outdated. For example, the programmers might spend a lot of time making sure that the FIFO scheduler of the operating system is efficient and uses less memory, when they should have spent time working on the next generation of scheduling algorithms that would be faster and more efficient.
In Chapter 6, they talk about how it's possible to ensure conceptual integrity when you may have one hundred different programmers working on the project. The important thing that the architect releases is the manual; this document must lay out all of the functionality that will be provided, including everything the user will see, but also must not provide any of the implementation details and leave that to the programmers. The architect can also specify the system using a formal definition, most usually described with the implementation. The problem with this is that sometimes it will over specify how things work in the system. And, sometimes defining by implementation means that developers view errors and bugs in the system as defined and standard output, causing problems with previously written programs when you update and patch the system. Meetings are also very important, but should have a structure and formal method for communicating and resolving disputes. Keeping a telephone log of all questions to the architect and their responses provides a history to look up whenever there are design issues again.
I didn't like this section as much as the first three chapters. It talked a lot about conceptual integrity, system architecture and design, and communicating these design paradigms to each member of the programming group. While the ideas are good, and it is important to have the architect formally define the design so you haves coherence, I think the design paradigm in XP is a much better process. Design should be minimal at the get-go, because usually it's not possible to know all the features and constraints at the beginning of the project. Yes, an architect (or customer, in XP) should define features they want, but those things shouldn't be set in stone. Instead, they should be looked at continually throughout the development process and changed to fit estimates and progress.
No comments:
Post a Comment