• 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
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Green Chipper -- light forestry and environmental services.
• Salt Spring Island Society for Community Education -- community education on our island of 10,000.
• 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

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.

• Pitfall 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 corporate policy.
• Pitfall 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!
• Pitfall 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.
• Pitfall 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!)
• Pitfall 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.
• Pitfall 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.
• Pitfall 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.
• Pitfall 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 influence altogether!
• Pitfall 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 and support.
• Pitfall 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.
• Pitfall 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!
• Pitfall 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.
• Pitfall 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.
• Pitfall 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.
• Pitfall 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.
• Pitfall 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.
• Pitfall 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 technology.

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.

• Principle 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.
• Principle 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.
• Principle 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 properly.
• Principle 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.
• Principle 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.
• Principle 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 standards.
• Principle 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.
• Principle 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.
• Principle 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 technology.
• Principle 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.
• Principle 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.
• Principle 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.

Conclusions

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

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 promise?

Postscript

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?

Post-postscript

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