Welcome to
OS/2 Headquarters

"Let's be serious.... Name a bank that didn't use OS/2."
-- Bill Gates, USA Today, June 30, 2003, page 3B


BOOK REVIEW: Who Says Elephants Can't Dance?

PRODUCT REVIEW: eComStation 1.0

Microsoft on Truth Serum:
the Antitrust Settlement Line-by-Line

USA Weather Radar
OS/2 News Sites
Computer Magazines
Generic News
Year2000 Sites
Internet Search Tools
Device Drivers & Files
OS/2 Shopping
Product Reviews
Technical Support
OS/2 Development
OS/2 Marketing
OS/2 Users
Seven LEAN Years
Shattered Windows
Understanding Microsoft
Understanding IBM
Classic Articles Archive
The Funnies Pages
About this Website
About the Webmaster
Bargain Headquarters
The Meaning of Life


July 2003

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.

Watch this space for future developments....


[ Top | Home Page | Faq ]

Copyright © 1998 - 2003, Tom Nadeau.
All Rights Reserved.

E-MAIL: os2headquarters@mindspring.com

Over cool people have visited this Website since January 1, 1998.