Stuff For Sale
2004 Summer Tour
In The Press
Veggie Van Gogh
Please patronize sponsors of this page!
Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
- Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
- Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
- Champagne Beadworks -- handcrafted jewelry and beadwork
- Crafted By Carol -- handcrafted jewelry and beadwork
- Dharm Atma Yoga -- Kundalini yoga instruction
- EcoReality, an organization devoted to establishing a sustainable ecovillage
- Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
- Environmental Education Outreach -- providing environmental education worldwide.
- Green Chipper -- light forestry and environmental services.
- Info Ark -- a huge collection of useful information.
- Varalaya Farm -- organic produce and sustainable farming education.
- Veggie Van Gogh -- two artists' mobile warehouse and living quarters, petroleum-free!
- Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.
This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!
Originally published in Object Magazine, September
The Overselling of Object Technology, or How To Fail On Your First
by Jan Steinman
The Promise of Object Technology
It's the latest bandwagon, and people are hopping on like crazy.
Some see it as a way to get an edge on their competition, others
simply want to reduce the cost of in-house projects, and still others
fear that not using object technology may damage their careers or
cost them their jobs.
Yet, objects are more than a mere fad. The use of object
techniques at any or all levels -- specification, design,
programming, and maintenance -- holds the promise of simplified
design, faster development, and greater reliability. System
developers love abstraction capabilities for the simplicity it gives
their requirements specification. Designers find that encapsulation
eases "chunking out" blocks of functionality. Implementors appreciate
not having to re-write (and re-test) all that reusable code. And
enforced modularity gives maintainers "Maytag Repairman" dreams.
However, the quickest way to get into trouble is to view object
technology as a panacea, by taking any of its advantages for granted.
Assuming specific benefits, especially in the early stages, causes
problems if those benefits are not actively pursued throughout the
project. The proper level of "buy in" is crucial -- not enough, and a
critical mass is not achieved. On the other extreme, there is a
difference between "buying in" and "jumping off a cliff!"
Perhaps most importantly, changing
technology without changing culture is like switching to automobiles
while retaining horse-and-buggy protocol -- you can get by for a
while, but sooner or later there is going to be a bad accident.
Avoiding the Promise
If all else fails, immortality can always be assured by
spectacular error. -- John Kenneth Galbraith
There are many ways you can get into trouble with object
technology. Here's a number of pitfalls that organizations use to
avoid the promise of object technology.
1: "That's just the way we do things
at MegaCorp!" -- Inflexibility is
perhaps the biggest reason object projects fail. You are trying to
use a new tool; don't cast it into old molds! For example, if
corporate policy is to have all code archived on the mainframe,
don't use that to dismiss an object-oriented source code
management system because it lacks tidy mainframe communication
facilities. The time it saves may be much greater than whatever
time is spent satisfying the intent, if not the letter, of the
2: Estimate the project in a traditional
manner, cut it in half, then sell upper management on the
technology, based on schedule alone. -- This is another
common object technology pitfall. Remember, this is going to be a
learning experience. Pitch the long-term advantages. If you really
need a short-term solution, you probably should not be proposing
any sort of new technology!
3: Since object technology is faster, budget
accordingly for resources, tools, and infrastructure. --
This is more than a simple corollary to my previous example;
infrastructure needs are different from timeline needs. Don't
expect to be finished after buying a compiler or deciding which
version of Smalltalk to use. Expect to pay several times your "per
seat" language cost on tools and training. To do otherwise is to
risk starving the project to death.
4: With the money you saved on
infrastructure, you can hire someone to maintain the cheaper tools
you obtained. -- Why stop there! Get rid of the compiler
vendor! Write your own! Hey, think of the money you could save if
you wrote your own operating system! (Yea, right!)
5: Get a single "guru," and do everything
he/she says. -- It is tempting to latch on to one person
who sounds convincing, and turn over all your tough decisions.
With two "gurus", you double your chances of success. The more
knowledgeable people involved, the less chance of building a
really crazy assumption into your system.
6: Staff up with experienced consultants,
but don't listen to them. -- In fact, don't even think of
them as consultants, they are merely "contractors," and are only
useful when their hands are on the keyboard! This bit of culture
will rapidly destroy a project, since your most experienced (and
probably most expensive!) object technologists will have the least
influence on the outcome.
7: Send everyone off to a week of training
and then expect them to get cranking -- that's all it should take
to learn a new language. -- That may be all it takes to
learn a new vocabulary , but absorbing the new
object-oriented concepts takes longer, and becoming familiar with
new idioms can only happen by reading lots of existing code, or by
working closely with an experienced person.
8: Isolate your permanent staff from your
consultants, after all, they've been trained. Consultants will
only distract them. -- If your only need is to have people
writing COBOL in Smalltalk, save a bundle and avoid outside
9: Hire a big consulting company (with
limited object experience) to deal with the problems that are now
becoming apparent. -- Since throwing bodies at the problem
didn't help, surely throwing new bodies with a different
perspective will! More likely, the new bodies will decide they
don't like the old bodies, and will spend most of their energy
trying to steer the project toward a technology they understand
10: Split the project along traditional
analysis/system/application lines -- to keep them independent, be
sure they report to different VPs. -- This organization is
common in traditional MIS environments, where reusability
currently means calling libraries. Entry into the object world
requires closer collaboration between the implementors and users
of components. It may be that each small group has both "system"
people -- those writing reusable components, and "application"
people using those components.
11: Make sure you're in control by putting
all your (inexperienced) permanent staff in the systems
group. -- If you must have different teams doing system
components and applications, involve outside help on the system
components side. Using object technology does not guarantee
reusability, it simply makes it easier. Forcing application
programmers to use a poorly designed and implemented system
components library is a sure formula for disaster!
12: Since objects make things so easy, plan
to eliminate programmers, and have the analysts and users do it
all. -- We aren't there yet. Screen generators help, but
are not perfect. Expect to have at least one object expert around
for the long-term. Experiment with end-user solutions while
continuing to deliver programmed solutions.
13: Object technology is more reliable, so
don't bother with standards, conventions and peer review
procedures. -- The biggest reliability advantages of object
technology, modularity and encapsulation, are easily
subverted. It is as easy to write bad
code in Smalltalk or C++ as in any other language. The need for
standards and conventions is greatest during the introduction of
any new technology. Of course, standards and conventions can be
oppressive; be prepared to let "natural selection" choose the
fittest standards and conventions, and let the others go.
14: Object technology is flexible, so feel
free to keep changing designs and specifications as the project
progresses. -- While a good object-based design is more
resilient than a traditional design, the need to keep making deep
changes in your basic design means that you aren't finished with
it yet. If your culture, project size, and development environment
can support an iterative, "spiral" development model, a changing
design will be distracting, but need not be fatal. However, if
your development model is strongly based on traditional
"waterfall" style, constant changes will kill your project no
matter what technology you use.
15: Don't commit; constantly examine other
options. -- This destroys morale and reduces productivity,
but more importantly, it also flavors
your design, as various influences that are not related to the
central problem come and go. If you make it to completion, you may
have something that caters to all and satisfies none.
16: Exploit object technology's rapid
development reputation -- demand immediate results, schedule lots
of 'dog & pony shows' early on to keep people working and to
impress upper management. -- If all you want is full
employment for your team, this will work as long as the project
lasts, which won't be too long. If you must provide this sort of
thing, shelter most of your people from these distractions by
appointing an "appeasement engineer" to handle demos. Negotiate
flexible demo schedules -- an honest "It isn't quite ready yet" is
better than getting everyone to drop what they're doing so they
can slap Band-Aids on an immature prototype.
17: When you've successfully avoided the
promise of object technology through these and other techniques,
you've got good reason -- the technology failed you. --
Smalltalk has to be the most-used scapegoat for poor project
management in recent history! (C++ projects have less room for
"scapegoatism", since a C++ project
should, in theory, turn out no worse than a C project.) Computer
technology is rapidly changing, and adapting to change is a
crucial skill for any computer technologist. If you find yourself
in this unfortunate position, be honest with yourself, and
consider that the technology didn't fail you, you failed the
Avoiding the Pitfalls
... a confusion of the real with the ideal never goes
unpunished. -- Goethe
I've described some common mistakes organizations make when
"trying on" object technology, but saying something is wrong doesn't
make it better. Here are some qualities that I've seen in successful
first object projects.
1: Be prepared to change your management
style and organizational structure to accommodate object
technology. -- For instance, involve your programmers in
analysis and design. Learn how to evaluate object-based project
progress. Foster cross-group communications and sharing -- invite
"them" to your peer reviews. Set up informal "brown bag" talks on
object topics. Be frank with your management about problems, with
the understanding that there are solutions.
2: Schedule as though you were using
traditional methods, then add at least 10% contingency. --
You are investing in the future; the payoff will come over the
entire project life-cycle. Subsequent follow-on projects will
provide many of the benefits.
3: Obtain the best tools and infrastructure
you can afford, and demand appropriate vendor support . --
Leave infrastructure to those who specialize in it, so that you
can devote your precious resources to what you specialize in, your
problem domain. Don't write anything you can buy, and don't
maintain anything you do buy, unless absolutely necessary. Since
the object toolsmithing market is so new, you can often negotiate
tool modifications with your vendor, rather than duplicate their
sunken effort into understanding their system enough to modify it
4: Learning is as far from knowledge as data
is from information. -- Invest not only in training, but in
apprenticeship and mentoring. You don't expect someone to become
proficient in French simply by reading textbooks, so be sure at
least some of your senior staff spend some time in France. A good
mix of external sources, such as hands-on apprenticeship and
experienced outside consultants, combines well with internal
knowledge propagation techniques, such as brown-bag sessions, peer
reviews, and "two on a tube" mentoring programs.
5: Use mentors to establish an object
culture. -- Be aware that you are embracing more than a
different language. Object technology is a whole new way of
viewing problems and solutions, and it won't happen overnight, nor
will it happen without some outside influence.
6: Have your most object-experienced people
establish project protocol -- standards, conventions, and
procedures -- and back them up. -- This may mean that you
give up some autonomy to outside experts while you "ramp up", but
the alternative may leave you with meaningless or even obstructive
7: Listen to all your experts. Get
suspicious if a consensus emerges that is different from what your
initial "guru" tells you. -- Today, good object techniques
are difficult to describe and measure, but are readily identified
when viewed through experience.
8: Avoid the big consulting
companies. -- They know little more about objects than do
you; they want to use your money to catch up. If you feel you must
use one of "the big four" consulting companies, use them for their
expertise (back end, communications, database, etc.), and keep
them away from the object part. Be sure to make them cooperate
with your object experts, or you will have a system that is 90%
"glue" and 10% functionality.
9: Isolate and nail down stable parts of the
architecture for early work. -- With a pilot project, you
have the luxury of being off the critical path, and can
concentrate on dealing with the inevitable distractions of any new
10: Protect the project from unnecessary
diversions. -- Establish object technology "buy in", from
your management, peers, and subordinates, as early in the project
as possible. This will keep your team focused on the dual problems
of learning a new technology and completing the project task,
without undue concern about what might happen next week.
11: Avoid early performance concerns. Make
it work right, then make it work fast. -- In typical
business software, "will the screen be updated quickly enough" is
dependent more on overall design than on whatever technology is
expressing that design. If you have an efficient design, you can
eventually make the implementation efficient. By allowing you to
deal in abstractions, object technology will let you concentrate
on performance issues at the design level.
12: Buy in for the long run -- it will pay
off! -- Tolerate short-term setbacks philosophically, and
take solace in short-term accomplishments, but keep in mind that
as the object expertise of you and your organization grows, you
will spend less time dealing with the technology, and will have
more time to devote to providing business solutions.
Be prepared to deal effectively with cultural issues. Traditional
MIS development environments that I've experienced seem ill-suited to
object technology. Your "programmers" will need greater access to the
big picture if they are to model it accurately using objects, and
your "analysts" will need to understand the low-level implications of
their design better. You might consider rolling them both into a new
job classification of "business engineer".
Use a staged implementation, if at all possible. Lead off with a
real pilot project that has visibility, but choose one that has some
schedule flexibility. This evolutionary process will give you a
chance to demonstrate object technology's strengths, while sheltering
the business from the learning process. At the end of the pilot
project, you should have a group of encultured, experienced object
technologists who can be used to seed new projects elsewhere.
If you must do all or nothing, be prepared to be distracted by
revolutionary problems, and schedule and budget accordingly. "Betting
the business" on any new technology might be dramatic, but you will
not be able to accurately measure success (or failure), since so many
non-technical factors will have been involved.
Finally, don't work in isolation! If you lack the budget for
extended apprenticeship programs, at least involve experienced
object-people in whatever way you can manage. If even this is
unavailable, obtain source for several well-regarded libraries, and
make it an informal policy to read ten lines of code for every one
To succeed with any new technology, you must be prepared to
surrender old assumptions -- object technology is no different. Those
who, for various reasons, wish to avoid the promise of object
technology can easily do so by viewing it through old biases Those
who succeed with object technology do so by viewing it as an
opportunity to change old biases. You can choose -- pitfall, or
November 23, 1995, Jan Steinman
This article struck a chord in the industry, and was excerpted or
quoted in at least eight other publications. But what have we learned
in the three years since publication?
We are still fighting many of the same battles, but there does
seem to be improvement. Three years ago, we were being hired to "do
this in Smalltalk," wheras today it's more like "is this a reasonable
thing to do in Smalltalk?" The need for mentoring is better
recognized, and managers expect to invest more time and money in the
conversion to objects, but there are still far too many people out
there looking for Fred Brooks' "silver bullet!"
On another topic, my editor on this article, Marie Lenzi, was
extremely helpful in targetting the audience of the day. I wanted to
do a Smalltalk article, but she wisely insisted that the article
encompass the greater realm of object technology, including the
dreaded C++. I wonder if the same decision would be made today?
January 26, 1999, Jan Steinman
In the three years since the postscript above was added, the industry
seems to have changed little with regard to "overselling object
technology," being distracted by the Internet craze and languages named
after hot beverages.
In fact, I'd say things have gotten worse. Object technology has
"crossed the chasm" into mainstream computing, in the words of Geoffrey
Moore, and is now perceived as "safe" to those who merely follow marketing
and trends, rather than make informed decisions. This has caused more
people to jump on the bandwagon, without regard to essential changes in
process and management.
This has resulted in many fiascoes, such as Corel's very public jump to
Java, then their humiliating return to traditional languages. 1999 may
well be the year of The Failed Java Project.
Where does Smalltalk sit now? The major Smalltalk vendors all jumped on
the Java bandwagon, albeit with tools based on Smalltalk. This may change,
as Java projects fail.
The sad part is that Java projects will fail for the same reason
Smalltalk projects fail, C projects fail, COBOL projects fail: it's the
process, stupid! I still think Smalltalk is the most flexible, moste
efficient environment, which makes it easier to get beyond the language
and think about the process. It remains to be seen if the market will