Sturgeon's Law

—Andy Hunt

02/01/1998
Published in Toolshed Newsletters

Welcome to the Toolshed Technologies Newsletter! In the spirit of the New Year, I’ll talk a little about Sturgeon’s law and some hopes and aspirations for the future.

Ninety percent of everything is crap.—Theodore Sturgeon

This famous, if somewhat bitter and depressing, quote typifies the frustration felt by many practitioners of the current state of the art in computing.

Abstraction is the key to success in designing and programming computer systems. Your favorite programming language should allow you to easily map an abstract problem domain onto the more constrained solution domain of data structures and logic.

Yet the current major programming languages fall far short of that goal: C++, the most popular object oriented (sort of) language on the planet, has inspired numerous articles on its manifest shortcomings. The added bloat from our good friends at ANSI, determined to make C++ All Things to All People, hasn’t helped. The culmination of the growing dissatisfaction with C++ is of course, the Java Hype Machine (or JHM)

Java, the virtual success. Java improves on C++, adding some fundamental features such as garbage collection, tightly integrated thread support, and the ever popular “Write Once, Debug Everywhere” model. But while Java managed to get a few things right, or at least better, it hugely misses the boat in some very fundamental areas: there is just enough type checking to get in your way, but not enough to ensure your safety. There is no genericty (templates or similar), there is no support for invariant assertions (as in Eiffel), it’s not as flexible as Objective C or Smalltalk, not as elegant as Eiffel, and not as fast as C++. This isn’t meant to be a lengthy bash at Java, but as one pundit put it “Java has the blazing speed of Smalltalk and the elegant simplicity of C++.”

And then there’s the methodology wars. An iterative, object oriented approach to analysis and design has clear benefits over a simple-minded, waterfall-style procedural design, yet the experts argue with near-religious fervor whether to use a cloud or a box to represent a class on a diagram!

Some of those arguments may be safely laid to rest with the advent of the UML, or Unified Modeling Language. Now instead of a single, coherent concept of model from one sharp mind, we have a committee of three wrestling with creating the ultimate, all-singing, all-dancing, able to generate the universe in a single bound, meta language.

All three of these leading technologies (C++, Java, UML) eventually suffer from the same ailment: conceptual bloat.

The original Unix operating system was based on the software equivalent of Occam’s Razor.

The explanation requiring the fewest assumptions is most likely to be correct.—William of Occam

Or as is commonly translated, The simplest solution is best. Small, sharp tools. That’s what made Unix such a wild success, the basis for internet computing, the mainstay of corporate client/server development.

Yet rather than stay with the concept of small, sharp (i.e., single, well-defined purpose) collaborative tools, we see the trend toward mega-suites of productivity applications, languages, and even (to an extent) operating systems.

Do you really need a hundred megabytes of Office97 installed to dash off a memo to purchasing?

Do you really need to type “public static void main (String[] args)” just to denote the entry point to your Java program?

The Peter Principle states that you will be promoted until you reach your level of incompetence. In a frighteningly parallel version, languages and methodologies are specified and grown to a point of bulk and unwieldiness whereby the next start up newcomer slays them with promises of speed and agility, only to succumb to the inevitable growth and death by committee once again.

Which brings us back to Mr. Sturgeon’s apt, if rather negative quote. So what is a practitioner of the computing arts to do?

Well, it important to remember that there is no single Right Answer for everyone for any given problem. What is right for you depends on the constraints you are operating under.

Despite the economic advantages of mass production, custom solutions (including mini-languages and application specific design tools) still have an important place in software development. Where off the shelf components, languages, or methods can be used – great! But be aware of the trap of trying to pound a round peg into a square hole. If you need a square peg, build it, from scratch if you need to. Software that doesn’t quite fit, like an off-the-rack suit, will never fit like a custom, tailor made one.

Can you afford such a development effort? Can you afford to spend the money and dedicate the resources to do it to perfectly fit your organization and unique circumstances?

In the hyper-competitive world of the next millennium, can you afford not to?

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.