A Personal Note
After many years of working as an independent contractor, I have just joined Oracle Corporation as a full time employee. This column, however, remains an independent activity. As before, the opinions I express here are my own.
I became an employee after so many years of independence partly for personal reasons, but global industry trends also influenced my thinking. I'd like to share that part of my decision making with you.
In the 1980s many companies were caught unaware by global competition. Many suddenly saw their vulnerability to takeovers if they were perceived to be using their assets inefficiently. The result was a massive move toward downsizing and outsourcing. Companies chose to obtain important services from outside vendors rather than from employees.
That pendulum has swung about as far as I think it's going to swing. In some of the leading companies in the computer industry, it's beginning to swing back. These companies have discovered their essential core businesses and competencies. They have come to realize that institutional memory, loyalty, and accountability are more important to them in these core areas than the benefits of using outside vendors.
For most of the last fifteen years I have been an independent vendor of computer-related services, and I've had little difficulty finding plenty of highly remunerative work. I could continue that way for at least another ten years, but the most interesting work at the best companies is moving inside. I think that trend will accelerate. Many independents will see the same trends I do and begin to associate themselves with companies. I decided to beat the rush.
[Postscript: My connection with Oracle was very brief. Shortly afterward, however, the reasons I cite here led me to begin a seven-year association with Documentum, which along the way became a division of EMC.]
While the US Congress and Justice Department focus on its browser integration and marketing tactics, Microsoft is preparing its final assault against IBM and the mainframe industry. Microsoft's goal is to establish Windows/NT based servers as the platform of choice for distributed electronic commerce. Toward this end, it has devised a multifaceted strategy for supporting distributed objects.
COM and DCOM -- Microsoft's Vision for Distributed Objects by Roger Sessions (Wiley, NY, 1998, 512pp, ISBN 0-471-19381-X, $34.99)
Roger Sessions was one of IBM's lead architects for its support of the Common Object Request Broker Architecture (CORBA) standard. He was also one of the Object Management Group's lead architects on the specification of its Object Persistence Service, one of the CORBA services. Sessions was not a big Microsoft fan when he set out to write this book, but as he began to understand Microsoft's plans, he became a believer.
Sessions believes that Microsoft has built a coherent strategy out of uninspired components. He says:
The main reason Microsoft's Java, COM, and DCOM are so exciting is not because they are wonderful technologies in and of themselves. If we want nothing more than Java programming, Sun offers a better solution. If we want nothing more than distributed components, CORBA is a better programming model than DCOM. What makes Java, COM, and DCOM so exciting is how they feed into a whole vision of how to write distributed applications. This vision includes sophisticated security, an entirely new model for efficient management of shared objects, and an incredible idea of clustered workstation machines, to name but three.
Sessions sees Microsoft's Visual Basic as a big piece of the picture. He predicts a future in which programmers use Java, and to a lesser extent C++, to implement the logic of applications and use Visual Basic to implement the user interface.
Two things make this book useful. Sessions has penetrated the jargon layer to expose the core of Microsoft's strategy, and he has put together a realistic example of sufficient depth to illustrate the essential issues. To read this book you should have access to a programming environment that includes Microsoft's Visual J++ and Visual Basic. If you reproduce the examples as you follow them in the book, you can get a good feeling for how it all goes together.
I recommend this book, but I have to offer one caveat. The publisher has not done a good job of editing. The book contains confusing passages and outright errors. Read it carefully, and trust your own judgment.
Usable Software and Documentation
User and Task Analysis for Interface Design by JoAnn T. Hackos and Janice C. Redish (Wiley, NY, 1998, 508pp, ISBN 0-471-17831-4, $??.??)
JoAnn Hackos and Ginny Redish are experts on usability of software and documentation. Both authors have written other highly regarded books, and both speak to packed audiences at professional society meetings. It was in a conversation after one such presentation that I discovered that Ginny Redish is related to Micro's editor-in-chief, Steve Diamond -- a fact I feel compelled to mention in the interest of full disclosure.
Hackos and Redish have written a practical book. They start from a piece of advice that every designer has heard and most designers try to follow: understand your users and the tasks in which they use your product. This is easy to say but hard to do. Hackos and Redish tell you how to do it. They explain how to observe and interview users at their workplaces and how to record and interpret the data you gather.
I find it telling that the first quarter of the book focuses mainly on justifying the necessary activity. Usability engineering is often hard to sell to managements that already pay plenty of money to programmers and writers. "We're paying top dollar for the best people," they reason, "so they ought to be able to figure that part out for themselves." If you encounter such views -- or if you hold them -- this book can help you understand the strong arguments against them.
While the book is about how to conduct site visits, the visits themselves occupy only two chapters. The bulk of the book deals with advance preparations and post-visit analysis.
Other books about this subject exist, but the authors of this one have applied their own techniques. Their long experience with usability and with technical communication have helped them write an extremely usable, readable, visually appealing book.
Like Hackos' earlier book Managing Your Documentation Projects (Wiley, 1994), this book presents a methodology that requires the efforts and commitment of more than one person to make it work effectively. By all means, read this book. If you agree with its ideas, you'll need to sell them within your organization before you can put them into practice.