|
In a democratic approach, design decisions
result in many variations which are not easy to
handle and often leads to complications in understanding
and taking up the design, writers
Dr R Srinivasan
The next antipattern to be taken
up for discussion is, 'Design by Committee'. It
happens more in the area of object oriented programme
development. If we trace the developments that
have taken place in software since the concept
of object-orientation was introduced, there is
an emergence of two different approaches. One
approach visualises object-oriented technology
where all designs are vertical. In this approach,
it has been assumed that the design process is
democratic, viz., every person in the design team
has an equal say-a typical example of egalitarian
approach and this is what results in the Design
by Committee Antipattern.
Under this situation, with many
features and variations to handle, it will lead
to complications understanding and taking up the
design to meet the required specifications. Because
of fact that many people in the design phase have
put in their part, resulting in acute complexity,
the design will not be understood on toto at a
later date, either during integration and testing
phase or during maintenance. Because the design
has been done in a fragmented manner by a committee,
the documentation part which is a vital one for
future guidance will also be complicated and at
times running to several pages.
It may be even be realized later
that there is lack of coherence between System
requirements Specification (SRS) and the actual
design. As pointed out by some experts, a situation
like this may also happen when people talk together
but work serially with less productivity. This
takes place particularly when there is no consensus
in deciding priorities of d4esign features; which
may be added to the specification based on proprietary
interests - a process called by the critics of
this process as, 'Gold Plating'. As Dr Thomas
Mowbray and Raphael Malveau in their book, CORBA
Design Pattern say, "Explicit priorities
and a software-value system are undermined".
As I had mentioned in the earlier
articles, it is absolutely essential to have software
architects as part of the project team; but in
the case of design by a committee the architects
and the project team have conflicting approaches
in the design phase. This is a typical case of
degenerate or ineffective software process. So,
in short, the antipattern solution of Design by
committee is that the designs are overly complex
and lack a common architectural vision.
What will be the impact of this
antipattern? The developers in the project team
face the situation of implementing a very complex
and sometimes ambiguous design. This puts a lot
of stress and mental strain on them, leading to
increased attrition rate. On this part the project
manager will face a big risk in completing the
project, meeting all the requirements of the customer.
Due to severe complexity in the design the planned
development schedule will get into disarray and
increase the cost for completion. The refactored
solution for this is to bring in good coherence
and conduct a productive meeting during design
phase. It is suggested that simple alterations
in the meeting process can yield substantial productivity
improvements.
Dean Herrington and Selina Herrington
in their book, Meeting Power, bring out one highly
effective meeting process called 'Spitwads', and
this is a very good model for conducting meetings
in any organization, let alone the software development
units.
In order to take care of every
detail in deciding the architecture and the succeeding
steps, William Brown, et al, give a brief account
in Lost Architecture Process, containing eleven
important steps to follow.
- Release a request for information (RFI).
- Review the RFI respons4es.
- Identify candidate services and facilities.
- Launch the Request for Proposal (RFP) process.
- Diagram the architecture in the form of block
diagram showing layers of services and horizontal
delineation.
- Define the preliminary services.
- Write service definitions.
- Draft the document.
- Review the process.
- Define the road map.
- Conduct the approval process in which a motion
is made to release the architecture and the
version 1.0 of the Road Map.
( To be continued)
(The
author is Chief Technology Officer, Internet Component
Management Group, Bangalore and can be contacted
at: r.srinivasan@iCMGworld.com)
|
