small medium large xlarge

Sturgeon's Law

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.

Occam’s Razor

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 and 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.

No Single Answer

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?