Internetworkers: http://www.ibiblio.org/internetworkers/

["Michael D. Thomas" <mdthomas AT mindspring.com>]

> I can remember raising the issue of  a
> lack design specs for the work our group was doing, and being told not to
> worry about it.  The exact quote was "If you put smart people in a room,
> they'll know what to do".

Yourdon comments on this theory in the Death March book. Intelligence is only
one component -- you can't forget motivation, insecurity, domain knowledge,
prejudices, dedication to teamwork, etc. Unfortunately, the intelligence is
focused on defending turf and appearing smart rather than solving the problems
at hand.

Quite often, the simple fact that an optimal solution can be found for any
given problem is lost in design meetings that seem more inspired by the field
of rhetoric than the field of mathematics.

Compared to implementation and testing, the cost of change is lowest in the
design phase. The cost of change is counted in minutes, not weeks and months.
In spite of this, the importance of design is often neglected.

 Alas, the design phase is the least rigorous, least pressurized and the most
prone to the subjective influence of ego needs. Design meetings can take on
the form of games. Often, the meetings are 'won' by whoever had the most
coffee that morning, or 'lost' by whoever had to go pick up the kids.

The malformations created by these meetings often lead directly to the
problems all the executives will be reacting to months later. As the product
is on the ropes, the executives think that they are dealing with inevitable
problems -- at least, that's what the engineers say. But often, the problems
wouldn't exist if the software design phase had been given more reverence.

The design phase can be the most costly with immature architects, who often
get design and requirements backwards. They sketch up some design, and then
invent requirements that justify the design. They then convince management
that the justifying requirements are crucial, thus making their design appear
to be the fruits of genius. "Configurability" is often used to justify the
immature architect's design b/c it sounds so good to management.

The architect's job is often filled with a recently promoted programmer. An
implementation background is great for architects, but programming is a much
safer task than design. A programmer's work is easily verified by the compiler
and the unit test. If your code works, your done. The machine verifies your
work. However, no machine is going to verify the accuracy of a large system
design. Undoubtedly, there is an optimal system design for any given problem,
but a lot of the hard work is understanding the problem. The architect has to
understand and define the context so that the best solution may be found. It's
as if the architect must write the compiler as well as the code. The
programmer-architect often forgets to write the compiler, or writes a compiler
that is solely intended to compile the design that took them, like, allll
afternoon.

(On the other hand, the non-programmer architect often borrows the
architecture from the most recent vendor's sales presentation, which of course
won't work. This usually leads to the architecture-less projects. As the
deadline looms, the vision of having a well-designed system is discarded and
developers are given line items and deadlines. Some code reuse may occur
completely by coincidence -- i.e., if two developers sitting close to each
other happen to be working on similar problems at roughly the same time, they
may collaborate. Surprisingly, these projects can be successful from a
functionality standpoint if the DB is well-designed and normalized. However,
they will be impossible to maintain.)

I think that commercial software shops have a lot to learn from open source
software when it comes to design. I think that the open source style design is
better because of, and not in spite of, email. Because of the lack of emotion
in email, ideas carry more weight than personalities. The ideas can be
reviewed and debated on their merits. In an organization, you can't bring the
same global scrutiny to bear on ideas. But the simple act of putting the goals
and substance of a software design in to words and diagrams transforms a
project from a subjective mesh of egos to the creation of a sound system
rooted in determinism.