OS/2 Headquarters
QUOTE of the MONTH:
"Let's be serious.... Name a bank that didn't use OS/2."
-- Bill Gates, USA Today, June 30, 2003, page 3B
What does it mean for a product
to have or to be "advanced" technology?
I guess it's sort of like fundamentalism. First, you have to agree on what the fundamentals
are. Then you can agree on what is really an "advance" and what is actually
decadent. In the technology world today, there seems to be a mindless acceptance
of the idea that the more features, options, and playthings that somebody stuffs
into a software package, the more "advanced" this product is. But that
is a fundamentally flawed assumption.
Keep in mind that just because you can add something, that does not mean that it
is necessarily a wise decision to do so. Burger King and Wendy's and McDonald's
want you to "Supersize" your food order, for example. Should you automatically,
mindlessly ingest more food, simply because the marginal cost is just a few more
pennies? The results are often a bloated, overweight customer who thinks that he
or she is a wise shopper. This sort of self-deception keeps companies in business
selling mediocre commodities while droning on and on about "great taste."
Similarly, monopoly products from commoditizers like Microsoft are often simply
bloated, overweight behemoths that have the tasteless, insipid flavor of a mass-market
hamburger. Some of these weighty wonders have the taste and texture of ground sawdust,
or perhaps rotting cardboard. But worse than that, software products that try to
be all things to everyone are sure to violate the fundamentals of system design.
I have derived a handful of such guiding principles that Microsoft and other "burgermeisters"
should learn and obey. I call them Nadeau's Three Laws of System Engineering.
Nadeau's First Law: The
complexity of a system is geometrically related to the number of subsystems it contains.
This is a subtle little feature
of systems. A large program that does a single task is not necessarily more complex
than a small program that tries to do many tasks. Size by itself is not the only
measure of complexity. While large size is often the result of merely bolting many
little systems onto one large one (like Windoze), such a system is certain to have
a higher level of complexity than a lengthy program that accomplishes a small number
of tasks. Sloppy, unreliable code is almost always the result of such an ad-hoc
and undisciplined design approach.
This is because of a concept called "intersegment interfaces." If we look
at each of the code modules as a segmented part of the whole, the complexity can
be estimated by observing the geometric relationship between the number of potential
interfaces among these segments or subsystems. For N segments, there are roughly
N*(N-1)/2 potential interfaces among these segments. For each such interface, there
are messages and data that must flow (usually bidirectionally) in an orderly and
routine manner. You can see that the design process will obviously get out of hand
as the number of subsystems gets beyond the single digits. A subsystem count of
4 will yield 6 potential interfaces to be specified, designed, coded, and maintained.
What happens when a software product consists of 20 or 30 other programs, snatched
from other software companies and innovators, and merged into the mix? Total chaos.
It should be obvious from this simple example that Microsoft's foolish decision
to merge the Web browser into the operating system has led to a chaotic, unstable
mess that can never be secured or maintained successfully. The whole thing will
have to be scrapped and redesigned from scratch. Which, of course, is what .NET
is all about.
Nadeau's Second Law: To
reduce complexity, reduce the number of subsystems so that information sharing among
them is minimized.
This follows directly from applying
the First Law. As you can see, this line of reasoning shows that it is not so much
the amount of software Lines-of-Code (LOC) that matters, as much as where
you draw the lines within that code. A 1000-line program with one task will
have relatively few subsystems and typically very little I/O to keep track of. A
1000-line program that does 10 different, distinct things will almost certainly
have many subsystems, each containing several variables. To which other subsystems
must each of the variables be exposed, to share and notify its state with others?
Structured programming is supposed to make tracking all these things easier, by
compartmentalizing these subsystems. However, it is much wiser to simply compartmentalize
at the highest level -- by not trying to produce a single program that is all-encompassing.
Windoze falls into the trap of trying to absorb every new feature, every new capability
or idea in the world of technology, into a single, amoeba-like entity. No wonder
it's such a joke!
What good does it do to compartmentalize at the code level, but haphazardly change
and escalate the system requirements (perhaps on a weekly basis) at the level of
requirements and design concepts? It's a software death-wish.
Nadeau's Third Law: The
effectiveness and reliability of any subsystem interface is directly related to
the personal relationships among the parties in charge of each subsystem.
Moving beyond basic math, consider
that communication among products can only occur if the coders (and certainly the
designers) of these products are communicating effectively at every stage of the
development process. This means that Microsoft's bitter, self-destructive internal
culture of rivalry and one-upmanship short-circuits effective communication among
the parties responsible for sharing interface data between subsystems and among
products. No wonder version incompatibilities and mismatched dataflows occur with
alarming regularity. Add to this mess the recent trend at many companies toward
rapid turnover of coders and engineers, so that few people ever have to be paid
for senior-level experience. Top it off with offshore outsourcing and cut-rate subcontracting,
and this is a recipe for disaster.
Software design of large systems requires thoughtful simplification of requirements
(modest goals), wise compartmentalization of subsystems (modular design), and long-term
stability of the development team (no short-term pandering to Wall Street, please!).
Selection of team leaders requires matching people with a friendly, open ability
to communicate, particularly across critical interfaces between pairs or groups
of subsystems. As you can easily see, Microsoft fails every test and disobeys every
one of Nadeau's fundamental system-design laws.
No wonder open-source systems and smart, modular products like OS/2 Warp (no blending
of the Web browser with the OS, thank you) are inherently superior to any product
that Microsoft will ever produce. Because Microsoft refuses to accept the fundamental
concepts of good engineering, they can never move ahead to becoming "advanced"
technology.
I don't have a Fourth Law of system engineering, but if I did, it would be:
From bloated, supersized egos come bloated, decadent products.
The contents of this editorial are the sole responsibility of the owner of this
Website
and do not reflect the opinions of any other individual or group.
