Java Reference
In-Depth Information
than intermediate Class III, their “easy” section started with a Class IV+ 8-foot
twisting waterfall.
Object technology, and associated iterative methodologies, have been the
most significant, and oversold, development improvements since structured
programming. While many see dramatic improvement in development cycle
times, others fall short of expectations. The journey into the unknown domain
of objects can quickly turn for the worse. As with my trip down the Piedra
River, you can suddenly find your plans working out badly. In the kayaking
community, I easily qualify as conservative. I do extensive research on every-
thing that I run. I scout anything bigger than a ripple. I set safety and carry
rescue gear. On the Piedra we had not communicated clearly with our well-
meaning guides. Against my better judgment, we had not scouted the river
and failed to see the real danger. We did not stop to ask critical questions of
the experts.
Often when we are being sold a new technology, external forces get in the
way. Others promote the new run as easier than Basic, more flexible than C++,
and faster than Assembler. We can get the Class V thrill with Class III risk.
Our eagerness and job pressures drive us to look for shortcuts. We may not
get the appropriate education or leadership, and may not even know that we
are in way over our heads until we are swept over that 8-foot fall and left swirl-
ing in the river.
Object-oriented systems add layers to shield us from complexity. We have
seen that necessary additional layers add value at a cost. Extraordinarily com-
plex frameworks can be built with relatively easy reuse. Each layer has the
potential to have an interface simpler than the last. If we ignore the cost of
each added layer, we can get into trouble quickly. If a system design has too
many layers through excessive wrapping, deep inheritance, or poor design,
performance problems can grow exponentially. Code can also grow too deep
to maintain. It is easy for increasing complexity to be hidden until we integrate
at the end of a project, only after huge investments have already been made.
In seven years as a systems programmer at
IBM
and in another five years as
a consultant, I saw this happen many times to experienced and talented teams.
Some problems are notorious for attracting solutions that are elegant but slow.
These are a few examples I participated in:
In the early and mid-1990s, graphical frameworks were such a problem.
I was a member of one of 20 or 30 teams throughout the industry that
were racing to build an object-oriented user interface framework. We
placed general wrappers around Windows and
OS/2
graphical objects.
