Amplifying Your Effectiveness, Seven Habits

This article appears in slightly different form in the September/October 2002 issue of IEEE Micro © 2002 IEEE.

The two books I look at this time deal with personal effectiveness. One is a collection of essays by Gerald Weinberg and some of his colleagues. The other is a runaway best seller, still relevant twelve years after it first appeared. I look at the ways in which these two books agree on all the important points.

Amplifying Your Effectiveness -- Collected Essays ed by Gerald M. Weinberg, James Bach, and Naomi Karten (Dorset House, NY, 2000, 160pp, ISBN 0-932633-47-1, www.dorsethouse.com, 800-342-6657, $30.45)

Gerald Weinberg (see Micro Review, July/August 2001) is an expert on making software practitioners, teams, and organizations more effective. He has been doing this for more than 30 years and is the author of many classics in the field. James Bach is an experienced software tester and trainer of testers. He is the founder of Satisfice, Inc. Naomi Karten is an expert on human behavior and communication in organizations. She is the author of several books on the subject.

This book grew out of the planning for the Amplifying Your Effectiveness (AYE) conference (www.ayeconference.com), a meeting that bills itself as designed to increase your effectiveness in leadership, coaching, managing, influencing and working in teams. The planners decided to set the stage for the conference by writing essays about their own experience. The editors arranged this material into a book.

In his introduction, Weinberg finds a pattern in the 19 essays that make up the book. He defines a taxonomy based on two axes: whose effectiveness is being amplified, and which aspect of effectiveness. On the first axis, he places:

1. Team member
2. Team
3. Organization 

Many essays deal with more than one of these, but Weinberg divides the book into four parts, based mainly on the first axis:

I     Empowering the Individual (1)
II   Improving Interpersonal Interactions (2)
III Mastering Projects (2)
IV  Changing the Organization (3)

On the second axis, Weinberg places the following general abilities that effective technical leaders have:

A. Observe situations and understand the significance of what they see.

B. Act congruently (that is, do the right thing) when confused, angry, or afraid.

C. Understand complex situations, and devise and execute appropriate plans to deal with them.  

Weinberg specifies where each essay falls on the second axis, so each essay has a pair of coordinates. Thus, for example, James Bach's essay The Role of Testing has coordinates 1C in the Weinberg taxonomy: it deals with a team member's effectiveness at understanding and dealing with complex situations. Rick Brenner's Ten Project Haiku has coordinates 1A, while James Bach's Good Practice Hunting has coordinates 3C.

Weinberg does not make the coordinate system explicit, nor does he carry it too far. If you look too closely it falls apart, but as an overview it can help in two ways. It can help you identify the areas you want to work on, and it can lead you to the material that will help you do so. It imposes a useful structure on what otherwise might appear to be a collection of tenuously related essays. And if you plan to attend an AYE conference, it can help you make the most of it.

James Bach's The Role of Testing is a wonderful example of how a job is what you make of it. His job stays the same, but his perspective keeps changing. At first he sees himself as engaged in finding problems. Enlarging his view, he then sees himself as assuring quality and analyzing risk. Taking an even broader view, he sees his job as helping the team understand what's going on. There is no way to know where this will end.

Consultants are a large part of this book's target audience, and the book contains a wonderful cautionary essay for consultants called Solving Other People's Problems by Paul Gray. He sets out a few simple principles, most of which I can remember violating to my own detriment at some time or other. For example, the Pay Attention principle warns that critical information often hides in plain view. The Passion principle (they all begin with the letter P) reminds you that it's a bad idea to care more about the other person's problem than the other person does. This goes hand in hand with the Partnership principle, which reminds you to keep the problem's owner involved at all stages of finding the solution, as in the proverb about giving a man a fish versus teaching him to fish.

Focus is an important part of effectiveness. In The Perils of Parallel Projects, Johanna Rothman quantifies the degree to which context switching reduces effectiveness. A person working on 5 projects, according to her numbers, spends 75% of the time on context switching and 5% on each of the projects. Most people know this -- qualitatively if not quantitatively -- but don't know how to get out of the situation when it happens to them. Rothman offers some suggestions.

Naomi Karten adds two brief articles from the point of view of a student of human behavior. They focus on seeing the people we deal with as fellow human beings. You don't have to be in a high tech industry to know that finding a common interest or experience helps people work together. Unfortunately, many people in high tech industries don't understand this intuitively or don't think it's important. Another impediment to good interpersonal relationships is labeling. In How to Deal with Irate Customers, Karten says to begin by banishing "irate," "unreasonable," "demanding," and other such labels from your vocabulary.

Of the five essays in the section on mastering projects, only two present the kind of material that usually appears in project management books. The others approach the subject more creatively. For example, Rick Brenner observes and advises in the form of 10 haiku (defined in the Merriam-Webster online dictionary as "an unrhymed verse form of Japanese origin having three lines containing usually 5, 7, and 5 syllables"). Brenner packs quite a bit of wisdom and humor into 170 well chosen syllables. My two favorites are:

I gave estimates.

They cut all of them in half.

Next time I'll pad them.

There is no more time,

but the work is unfinished.

Take more time from Test. 

Johanna Rothman takes another creative approach to project management in her essay It's Just the First Slip. She tells you to listen to your project. The first slip is a whisper: "Your expectation is not matching my reality. Listen to me. I can tell you my reality." By the fourth slip, it's yelling "You'll pay for this!" 

Brian Priorek's contribution to the genre of creative project management writing is an account of how he kept his head in a chaotic project -- breakfast in bed for his wife on their anniversary -- and brought it to a satisfactory conclusion, despite inadequate preparation, challenging personnel issues, and lack of tools.

The essays that deal with changing the organization are in many ways the most important, but the hardest to put into practice.

Steven Smith describes the Satir change model. Virginia Satir is a family therapist whose work inspired Gerald Weinberg's More Secrets of Consulting (see Micro Review Jan/Feb 2002). Smith describes Satir's stages of group change and provides ways to keep things moving forward successfully at each stage.

James Bach, who begins the book with The Role of Testing, ends it with a provocative essay about best practices and the myths that go with them. For example, he examines the widely recognized best practice of performing unit testing as a part of software development. Almost all companies say they do this, but few actually do so, according to Bach's definition of unit testing:

The testing of individual modules, functions, or classes without regard for their integration with the rest of the system, where the goals are to find problems before integration and to find those problems that are difficult to isolate on a subsystem or system level.

Most companies call whatever testing developers perform on their own code unit testing. The typical methodology is: I exercise the code and see if it works.

Bach cites other myths about testing:

It's important to repeat the same tests on each new build.

It's important to document all test cases and procedures.

It's important to create tests based on specifications well before it's time to execute them.

Each of these best practices is good to do in some situations, but not in others. The problem, Bach says, is that the software industry consists of many broad communities of practice (for example, regulated, high reliability, market driven), and what's important for one may not be for others.

As you can see, this small book covers a lot of ground. The essays are all short and easy to read. They don't require much specialized knowledge. They are filled with information that most of us can use right away. If you have anything to do with software development projects, you should read this book.

The Seven Habits of Highly Effective People by Stephen R. Covey (Simon & Schuster, NY, 1989, 360pp, ISBN 0-671-70863-5, $14.00)

It would not have occurred to me to review this book, which has already sold 10 million copies in the 12 years since it appeared, had it not been for a coincidence. When I first picked up Amplifying Your Effectiveness, I had just participated in a workshop based on Stephen Covey's ideas, so those ideas were fresh in my mind. I saw immediately how closely Weinberg's taxonomy of improving effectiveness parallels Covey's habits. Looking deeper, I found many other places where these two books say the same thing in different ways.

The icon of Covey's habits is a figure resembling an hourglass inside a circle. The lower triangle represents the three habits that comprise the private victory, that is, the move from dependence to independence. The upper triangle represents the three habits that comprise the public victory, that is, the move from independence to interdependence. The circle represents the seventh habit, which concerns continual personal renewal.

When I first saw Weinberg's first axis in Amplifying Your Effectiveness, it reminded me immediately of Covey's hourglass figure.

Weinberg's second axis also lines up with some of Covey's principles. For example, Covey's first habit concerns breaking the connection between stimulus and response. Rather than reacting to anger or fear, pause a moment to think about how the person you want to be would respond in this situation. This corresponds pretty closely to acting congruently when confused, angry, or afraid.

Another of Covey's habits, seek first to understand, then to be understood, lines up pretty well with the other items on Weinberg's second axis.

Covey sees effectiveness as based on keeping a balance between your production and your capacity to produce. The story of the goose that laid golden eggs expresses this idea. The goose's owner sought ways to obtain eggs faster than the goose could produce them, and in doing so killed the goose. Covey's habits are about building your production capacity and performing within its limits. For example, Covey's third habit, Put first things first, is exactly the advice Johanna Rothman gives in her article The Perils of Parallel Projects. To reduce context switching, she suggests picking the most important task and working on it until it's finished.

Covey's third habit gives rise to one of the best known aspects of his book, his time management matrix. Covey characterizes tasks on two dichotomies: (important, not important) and (urgent, not urgent). This gives rise to four quadrants. Covey's time management strategy is to spend as much time as possible in quadrant II, important but not urgent. This prepares you to handle quadrant I (urgent and important) tasks efficiently and reduces the number of such tasks.

I could go on and on drawing parallels between these two books, but I'll leave the rest as an exercise for the reader.

Covey's book is an intricate interweaving of simple themes. It is a book to read and to refer to again and again. I recommend it highly.

The FranklinCovey company (www.franklincovey.com) offers workshops on the contents of the book, and many companies make these available to their employees. If you get a chance to attend one of these workshops, you should take advantage of it.

Effective Java, C# Essentials, Essential Java Style

This article appears in slightly different form in the July/August 2002 issue of IEEE Micro © 2002 IEEE.

Programming Books

This time I look at books designed to help you program in Java and Microsoft's new language for the .NET framework, C#. When I first wrote about Java (Micro Review June 1996), I said

I think Java will eventually replace C, but I think C++ will persist as its competitor for a long time. That conflict will probably follow the model of the RISC vs CISC wars, so that ten years from now it will be hard to know which is which.

There are still four years to go for that prediction, but whatever happens to C++, it's already hard to tell C# and Java apart. The books I look at this time often sound as if they are quoting each other, almost word for word, whether they deal with C# or Java.

Effective Java by Joshua Bloch (Addison Wesley, New York NY, 2001, 268pp, ISBN 0-201-31005-8, www.awl.com/cseng $39.99)

Joshua Bloch is the ideal person to write about using Java effectively. He has a distinguished academic background and works as a software architect at Sun, where he has been since 1996. He designed and implemented the collections framework and the java.math package.

Bloch borrows the title and format of his book from Scott Meyers' Effective C++. When I reviewed Meyers' book (Micro Review, Nov/Dec 1994), I wrote that Meyers should have titled it "C++ Traps, Pitfalls, and Swindles" (an allusion to a chess book by Fred Reinfeld). I wrote

You can look at this book two ways. From one point of view it is an enormously helpful compendium of practical advice on C++ programming. From another angle it is a point-by-point condemnation of C++ as an unusable, unintuitive programming language.

I'm happy to say that only the final two chapters -- on threads and serialization -- of Bloch's book make me feel that way. The behavior of threads appears to be quite unintuitive and to depend on a continually changing memory model. Serialization appears to have insoluble problems, because it conflicts with the modularity and encapsulation that are at the heart of the object oriented model. The remainder of the book, however, leaves me with a decidedly more positive impression of Java and the care with which Sun continually reviews and improves it.

I do not always read every word of books that I review, but I read every word (and every line of code) of this one. I read it sequentially from cover to cover, but you don't need to. Like Meyers' book this one consists of short essays (57 in this case), grouped into 9 topic areas. Bloch wrote the essays independently, so you can just read what interests you. I found all of it fascinating.

Bloch writes about Java programming style, but rather than doing so abstractly, he stands knee-deep in implementation details. He often bases his analysis of a situation on how the Java virtual machine is likely to behave. He also brings in his deep knowledge of and respect for the Java libraries. He points out that it's foolish to waste your time inventing ad hoc solutions to problems, when experts have already solved those problems and made the solutions conveniently available in libraries like java.lang and java.util. This seems too obvious to mention, but many programmers, unfortunately, need to hear this advice.   

Object oriented programming is a good example of the principle that there's no such thing as a free lunch. Bloch's essays entitled "Favor composition over inheritance" and "Design and document for inheritance or else prohibit it" illustrate this point clearly. You promote reuse if you provide a class with the intent that someone in another company working in a different package can extend it (that is, create a subclass) by overriding some of its methods. The costs of doing this -- often overlooked, even by experienced designers -- are reduced modularity and greater vulnerability to errors or malicious attacks. Allowing subclassing reduces modularity because you must document details of your implementation. For example, you must say (and commit never to change) when and why you invoke the overridable methods within your own class -- details that would otherwise remain private. Allowing subclassing increases vulnerability because you must also declare some methods and fields of your class to be protected, that is, available to the subclass. If you were not making the class available for subclassing, you would declare those methods final and the fields private.

The essays just discussed are in Bloch's chapter on classes and interfaces. Many companies sell Java-based software. They design interfaces and provide classes to implement them. How well they do this can mean the difference between a successful product and one that generates more support costs than revenue. If your company sells Java-based software, it's a very good idea to ensure that you are familiar with the issues Bloch discusses.

The other parts of this book are just as valuable. Bloch consistently returns to the themes of usability, robustness, and flexibility. He also addresses efficiency (for example, pointing out the costs of string concatenation), but warns that optimizations often cost more than they save. He also points out that the design of the public interfaces can sometimes have a much greater effect on performance than tinkering with implementations. First write a good, modular program. Then measure performance with profiling tools to find out where the bottlenecks are. Tinker with the few small places that might have a big effect. Then measure again, because optimizations don't always have the effect you think they will have.

Every bit of this book is essential for Java designers. Reading this book before you start delivering products can easily repay its cost thousands of times.

C# Essentials, 2ed by Ben Albahari, Peter Drayton & Brad Merrill (O'Reilly, Sebastopol CA, 2002, 202pp, ISBN 0-596-00315-3, www.oreilly.com, $24.95)

The C# language is Microsoft's answer to Java. Java programmers should have no trouble learning to program in it. Rather than running on a Java virtual machine, C# runs on the .NET runtime environment, which is called the common language runtime (CLR). All languages on the .NET platform compile into CLR modules and can interoperate with each other, including seamlessly using each other's objects and classes.

This book provides an excellent overview of the basic language and its features. Like Java, however, C# relies on an extensive library. For C# the library is the .NET framework class library (FCL). This book provides only the sketchiest overview of the FCL. As it has for Java, O'Reilly will probably produce a large stack of books on the C# library and environment. Until then, you'll have to work with the overview documentation that Microsoft provides with the .NET framework and its software development kit (SDK).

One interesting feature of the FCL is its support for regular expressions. This is a natural outgrowth of Microsoft's support for XML. If you're going to be working with a lot of plain text files, which is what XML files are at heart, you need powerful tools for manipulating them. Regular expressions provide such a tool. The book provides a nice summary of the FCL support for regular expressions, which parallels that of the Perl language.

The book is short. It does not pretend to be more than a concise summary of the language and its relationship to its environment. Nonetheless, it contains lots of useful information. The writing is clear and concise, and the material is well organized. If you're starting to program in C#, this is a good book to have handy.

Essential Java Style - Patterns for Implementation by Jeff Langr (Prentice-Hall, Upper Saddle River NJ, 2000, 300pp, ISBN 0-13-085086-1, www.phptr.com, $39.99)

This is a helpful book on the nuts and bolts of writing good Java code. At the same time it is an annoyingly curmudgeonly work. Langr continually rails against decisions that the designers of Java made a long time ago. Nobody can do anything to change those decisions now, so this carping is of little use to his readers.

Langr's subtitle plays on the idea of design patterns, a widely accepted way to describe and name designs for programming subsystems. Langr, however, does not write about architecture at that level. His patterns deal with designing and coding individual modules.

Langr blends valuable content with a clear, easily comprehensible, and visually effective presentation framework. He presents close to a hundred patterns, grouped into six groups, or categories. Each pattern answers a specific "How do I . . .?" question, making the book task oriented -- a rare but much appreciated characteristic of a programming book. Langr presents the patterns in a visual style reminiscent of good API documentation. Each pattern's entry begins with the pattern's name followed by a boxed table containing the question the pattern answers, a summary of how it does so, and references to related patterns. Langr follows the table with a few explanatory paragraphs and annotated code examples.

Langr gives his patterns names, rather than numbers, so that people can remember them more easily. This is a good idea, but names and numbers are not mutually exclusive. By numbering his patterns as well, he can make it easier for programmers to navigate to the information they are looking for. I hope he adopts this practice in future editions.

Langr comes from a Smalltalk background. Many of the underlying ideas come from Kent Beck's Smalltalk Best Practice Patterns (Prentice Hall, 1996). Few Java programmers are likely to have read that book, so this adaptation for Java will bring the patterns to a much larger audience.

In addition to the chapters that describe the patterns, Langr provides two other valuable discussions. The first is a long annotated example that illustrates many of the patterns. The second is a collection of hints for achieving good performance. Langr purposely avoids discussions of performance in most of his patterns. In this section he addresses a few Java-specific optimizations. Because implementations change, these hints may not apply to later versions of Java, but many probably will.

The book is a little dated, because it refers to Sun's JDK 1.1 and 1.2. Most of the information is still valuable, but a new edition would enable Langr to incorporate recent improvements and to remove obsolete warnings and workarounds. Even so, this book is well worth reading.

Enterprise Computing

This article appears in slightly different form in the May/June 2002 issue of IEEE Micro © 2002 IEEE.

In the March/April 1998 Micro Review, I reviewed a book by Roger Sessions about Microsoft's vision for distributed computing. Microsoft has continued to march down that road. As I found out at the VSLive conference in February 2002, they seem to have assembled all of the pieces (COM+, .NET, C#, Visual Basic) and are ready to put them together with XML into something called web services.

At the same time, Sun's strategy has been more visible. The Java Two Enterprise Edition (J2EE) has been in widespread use for two years. As I found out at the Java One conference in March 2002, Sun is extending the J2EE platform and using XML technologies to enable something called web services.

Books about these approaches abound. This time I look at a generic book about web services and several books about the Java approach to providing them.

Enterprise software is not an end in itself. I also look at a book that deals with content -- the reason for all that software.

Finally I look at a book about a topic that never seems to go away -- improving the software development process.

Web Services

Web Services Essentials -- Distributed Applications with XML-RPC, SOAP, UDDI and WSDL by Ethan Cerami (O'Reilly, Sebastopol CA, 2002, 288pp, ISBN 0-596-00224-6, www.oreilly.com, $29.95)

A web service, according to this book, is any service that is available over the Internet, uses a standard XML message system, and is not tied to a specific operating system. This general definition gives little insight into what they will look like and how they will affect our lives. I went to VSLive and JavaOne looking for a clearer picture, but they didn't give it to me. I am sorry to say that reading this book did not give me a clearer picture either.

The book does, however, give a good introduction to the technologies that everybody seems to agree will underlie whatever web services turn out to be. Those technologies are the acronyms mentioned in the book's subtitle: XML-RPC (the XML-based remote procedure calling protocol), SOAP (the simple object access protocol), UDDI (the universal description, discovery, and integration specification), and WSDL (the web services description language). These are the building blocks of a loosely coupled architecture for distributed applications.

Cerami is a programmer, and he writes for programmers. If you wish to understand the business case for web services, look for a different book. Cerami focuses on details of how to use the base technologies. Real XML files and real code fill the pages of his book. If you like to dig into such details, this book should make you happy.

Java Web Services -- Using Java in Service-Oriented Architectures by David A. Chappell and Tyler Jewell (O'Reilly, Sebastopol CA, 2002, 262pp, ISBN 0-596-00269-6, www.oreilly.com, $39.95)

At first glance this looks very much like the Cerami book, and you may wonder, as I did, why O'Reilly brought out such similarly titled books at essentially the same time. I don't have a good answer, because there is considerable overlap -- Cerami's book is full of Java code, for example. The Chappell and Jewell book, however, focuses more on the Java aspects of the subject. It also seems to cover the subject area more broadly. If you intend to work mainly on the J2EE platform, you can probably start with this book and skip the Cerami book.

Chappell and Jewell see interoperability as the point of web services. The service-oriented architectures they refer to in the book's subtitle are frameworks in which new and existing enterprise software packages can work together without knowing too much about each other's inner secrets. 

A service-oriented architecture is like a dating service for client/server relationships. Servers advertise their services (for example, I provide stock price quotes) in a registry. Clients look in the registry for a suitable server. They use the information they find there to establish contact, over the Internet or a company network, with the server and obtain the desired service (for example, tell me the current price of Microsoft stock).

Making this sort of thing work smoothly, without human intervention, between systems using disparate operating systems and languages requires an alphabet soup of standards. In addition to SOAP, UDDI, and WSDL, my notes from JavaOne mention:

• ebXML TRP, a business-to-business messaging standard based on SOAP
  
• JAX-RPC, a set of rules for generating Java code from WSDL
  
• JAXP, an API for parsing XML into SAX or DOM
  
• JAXR, an abstract layer to hide differences between registry APIs
  
• JAXM, a low level API, based on SOAP, for messaging

That doesn't include the ones that don't exist yet (JAXB and JSR-109, for example).

As anyone who has participated in standardization efforts knows, many factors influence the final outcome. And the final outcome is rarely final, because the pressures of ongoing development and de facto standards lead to a succession of versions, each introducing new features. Multiply this chaos by the number of standards involved in web services, and you can see what a confusing field it is.

Chappell and Jewell realized that a big part of their job in writing this book was to separate truth from hype and software from vaporware. They do a good job of making sense of the field as it is now (or was in March 2002 when this book appeared).

A wise developer, looking at this situation, would probably decide to wait a year or so for web services to settle down. But many companies, not wishing to miss the next big thing, are jumping into web services with both feet. If that's the situation you find yourself in, this book can save you a lot of grief. Don't approach web services without it.  

Java Enterprise Applications

As they did last year, Sun gave attendees a book at this year's JavaOne conference. Unlike last year's book, which contained interesting but disjointed case studies, this book focuses on application architecture. Arising out of the Java BluePrints program, this book lays out design patterns and best practices for building enterprise applications on the J2EE platform.

Designing Enterprise Applications with the J2EE Platform, 2d ed by Inderjeet Singh et al. (Addison-Wesley, Boston MA, 2002, 440pp, ISBN 0-321-12522-3, www.awl.com/cseng, $44.99)

The web services field is arcane and chaotic. J2EE application architecture is mature by comparison, and this book illustrates that point extremely well. You could use it as the textbook for a college course on the subject. Despite the large number of authors, the book is coherent and clear. It appears to speak in a single voice and tell a single story, without gaps or overlap. To my knowledge, nothing remotely like it exists for the .NET platform.

This book arises from the Java BluePrints program. In fact, its unofficial name is the BluePrints book. It culminates with a sample application (the Java Pet Store) that illustrates the principles and design patterns that the book discusses. The entire program, and this book in particular, are a model for the way all companies should support their products for developers. If you have anything to do with developing enterprise applications on the J2EE platform, drop everything and read this book from cover to cover.

  

Mastering Enterprise JavaBeans, 2d ed By Ed Roman, Scott W. Ambler, and Tyler Jewell (Wiley, New York NY, 2002, 672pp, ISBN 0-471-41711-4, www.wiley.com/compbooks, $45.00)

Ed Roman, CEO of the Middleware Company, is a developer who has been working with Enterprise JavaBeans (EJB) since they first appeared. He has taught the subject to many students. Scott Ambler is a columnist for Software Development and the author of many books on object oriented development methods. Tyler Jewell is a technology evangelist for BEA Systems and an expert on EJB. The first edition of this book, which appeared three years ago, was widely admired. Taking all that into account, I expected this to be an excellent book, and it lives up to that expectation.

To paraphrase Mark Twain, Enterprise JavaBeans are to JavaBeans as lightning is to a lightning bug. EJB is the Java equivalent of Microsoft's COM+ (see Micro Review, Nov/Dec 2001). It is a robust server-side technology designed to handle tricky functionality automatically in the runtime environment. Application programmers need not worry about transactions, persistence, or caching database information, for example. The EJB container can take care of these things for them.

This book teaches you EJB from the ground up. While far too many computer books are superficial -- filling an impressive 1000 pages with regurgitated manuals and specifications, this thick book is concise and focused. It deals with difficult issues and refers you to Sun's specifications for the minute details. It is both a textbook and a tutorial, but not the sort of tutorial that leads you through page after page of baby steps. It shows you code, discusses the key issues, and lets you try it out if you wish to do so. You can download all of the code from the book's website.

When Ed Roman first encountered EJB, he struggled for months to understand the specification. Having become an expert the hard way, he resolved to write the book he wished he had been able to read then. Why reinvent the wheel? If you need to work with EJB, read this book.

Content

Enterprise Content Services by Greg Laugero and Alden Globe (Addison-Wesley, Boston MA, 2002, 204pp, ISBN 0-201-73016-2, www.awl.com/cseng, $29.99)

Greg Laugero is an expert in managing intellectual capital. Alden Globe is an expert in knowledge management. Together they founded Industrial Wisdom, LLC, a company that focuses on providing enterprise information to the decision makers who need it.

This book tries to put the horse back in front of the cart. The authors point out that managers often mistakenly assume that acquiring the right technology will solve their problems. The truth, however, lies in the old saw: first devise the process, then automate it. In the case of content management, this means examine your business goals and strategy to identify your information needs, then devise ways to develop and deliver that information automatically.

The authors devote a considerable portion of the book to an elementary explanation to managers about why they need to manage their enterprise information within the context of their business strategy and how to measure the benefits of doing so. Many managers in high tech firms probably already understand this. They should find the rest of the book much more interesting.

The authors move from the why of content management to the how of it. They lay out a practical, easy to follow process for identifying the enterprise information that is relevant to your business needs and for managing that information to meet those needs. They build this process around the following basic elements: knowledge storyboard, content inventory, and enterprise content catalog. These elements are just what you think they are, but the authors provide lots of practical advice to keep them from becoming too elaborate. Their basic ground rules are:

• Know the business problem and know the content
  
• Acknowledge that people and processes drive technology
  
• Be aware that the catalog is the foundation
  
• Think big, work small, deliver quickly
  

The main point of these rules is to focus you on a process that meets your business needs, not on flashy technology. If this book achieves that goal with a significant number of readers, perhaps it will help content management vendors focus more on the quality of their offerings and less on the lengths of their feature lists.

 

Process Improvement

Making Process Improvement Work -- A Concise Action Guide for Software Managers and Practitioners by Neil S. Potter and Mary E. Sakry (Addison-Wesley, Boston MA, 2002, 196pp, ISBN 0-201-77577-8, www.awl.com/cseng, $29.99)

Potter and Sakry are cofounders of a company that consults in the area of software process improvement. Both have been working in this area for many years. Like the content management book by Laugero and Globe, this book tries to bring its subject down to earth. It focuses on identifying specific business problems and addressing them with simple, practical, targeted steps.

Many companies take achievement of a specific level in the Software Engineering Institute's Capability Maturity Model (CMM) as a goal in itself. This leads them to introduce processes and paperwork into their already busy workflows without a clear idea of what all of this red tape is supposed to accomplish. Project teams quickly abandon these additions or learn to go through the motions. The business problems remain as they were.

Potter and Sakry suggest a different approach: focus on your organization's goals and problems, and tie improvement activities directly to current project work. Solve the most important problem first. When that solution is succeeding, address the next problem. Look at how your solutions relate to the CMM, but don't make your solutions broader than they need to be to solve the business problem. You can apply Laugero and Globe's maxim here: Think big, work small, deliver quickly. A little momentum goes a long way.

The book is concise. It contains a step-by-step procedure for identifying, simplifying, and carrying out process improvements that solve real problems. If anybody in your management has ever mentioned the CMM, you should buy this book.

Learning Proven Lessons

This article appears in slightly different form in the January/February 2002 issue of IEEE Micro © 2002 IEEE.

The books I look at this month cover a wide variety of subjects, but they are all about learning. None of them deals with a brand new topic. Two of them are new editions of successful books about important topics: XML and Perl. Two are successors or companion volumes to other works by the same authors: Gerald Weinberg on consulting and Kendall Scott on the Unified Process. One applies old principles to designing websites -- a no longer new, but still largely undisciplined activity.

These books illustrate an important idea. Fads come and go, but there is no magic. Fads become disciplines through patient progress, trial and error, and applying proven principles to new situations.

New Editions

XML Handbook, 4th edition by Charles Goldfarb & Paul Prescod (Prentice-Hall PTR, Upper Saddle River NJ, 2002, 1164pp plus 2 CDs, ISBN 0-13-065198-2, www.phptr.com, $49.99)

Prentice-Hall produces a series of XML books under the title The Charles F. Goldfarb Definitive XML Series, and this book is the flagship of that series. Some books in the series are pro forma attempts to describe logically necessary pieces of the XML world. They leave me unsatisfied, wondering "where's the meat?". This book, however, contains an overwhelming amount of meat.

On his website, www.xmlbooks.com, the senior author, Charles Goldfarb, lists and comments on hundreds of XML books, including 15 that he personally recommends. This one is first on his list. Here is what he says about it:

Everyone involved with the Web needs to know about XML: content creators, Website developers, programmers, and — most of all if you want your projects funded — managers. What reviewers have praised most about The XML Handbook is its ability to reach all these people, while still maintaining the accuracy and completeness that its technical readers require. So much has happened in the XML world since the last edition was published that we've prepared a revised and enhanced fourth edition with over 1200 pages and two CD-ROMs.

This may seem like shameless self promotion, but it's accurate. Goldfarb is essentially the father of XML. His deep involvement and many contacts make it possible for him to understand, make sense of, and explain the many application areas that have embraced XML. 

Many industries and application areas have turned to XML to help them standardize their information structures and business interactions. This has led to an alphabet soup with an oversupply of Xs. This book helps to sort out and demystify the new standards and terminology.

The accompanying CDs are a strong point of this book, because there are so many XML-related tools. It's hard to know which ones address the problems you're trying to solve, and of those, which are efficient and reliable. By collecting a large number of excellent free tools and explaining what they do, the authors have performed a service that you would have to spend a large amount of time to duplicate.

With all of this, XML is still a daunting area. Reading a book of nearly 1200 pages and exploring the contents of two CDs requires a large commitment. There's no royal road, but when you make that sort of commitment, it's nice to know you're not heading down the wrong path.    

Learning Perl, 3rd edition by Randal Schwartz & Tom Phoenix (O'Reilly, Sebastopol CA, 2001, 334pp, ISBN 0-596-00132-0, www.oreilly.com, $34.95)

People in the Perl community call this the Llama Book, because the cover bears the picture of a llama. Over the last nine years, thousands of programmers have learned Perl from the Llama Book.

I did not like the second edition of this book (Micro Review, December 1997) because I found many technically significant errors in it. When beginners see an unexpected result, they often cannot tell whether they have misunderstood an essential fact or simply encountered a harmless typo. For this reason, a tutorial full of errors is very hard to use. In response to my queries about the errors, O'Reilly technical support sent me a long list of corrections, so I assume they have fixed them all in this edition.

If this edition of the book is substantially error free, it's certainly worth looking at. The authors have a great deal of experience teaching Perl face to face with students. Their presentation and exercises have evolved as a result of that experience. In fact, they have essentially rewritten the book to follow their courseware more closely. Some of the structural changes make the material easier to digest. For example, they provide a gentler introduction to regular expressions -- a subject that could easily fill a book by itself. In fact, if you become intrigued with regular expressions, there is a whole book about them, Mastering Regular Expressions by Jeffrey Friedl (Micro Review, December 1997).

Unlike Charles Goldfarb, these authors are not the fathers of the subject they are writing about --  that distinction goes to Larry Wall. They are, however, recognized experts, active in the Perl community. Like Goldfarb, they can show you a path through a daunting body of material. The Perl community, like the XML community, is actively extending its reach, and it takes experts like Schwartz and Phoenix to keep track of all of that work and explain its significance. I like the fact that the authors tell you up front that you're not going to learn the material in a few hours.

If you're ready to learn Perl on your own, or if you want to teach an introductory course in Perl, this is the book to measure all others against.

Companion Volumes

More Secrets of Consulting -- The Consultant's Toolkit by Gerald M. Weinberg (Dorset, New York NY, 2002, 214pp, ISBN 0-932633-52-8, www.dorsethouse.com, $39.45)

In my review of the SHAPE Roundtable on Project Management (Micro Review, July/August 2001), I pointed out that some of the shared images that make that discussion work come from Gerald Weinberg's Secrets of Consulting (Dorset, 1985). Now Weinberg presents more secrets and a whole new set of images. The yes/no medallion, for example, reminds you to mean it when you say yes or no. And every time someone mentions the yes/no medallion in a discussion, I will think of the chapter from hell, Weinberg's wonderful illustration of why yes should mean yes and no should mean no.

In earlier books, Weinberg established many famous laws. This time he uses the metaphor of a consultant's toolkit to store items like the yes/no medallion, but he hasn't given up on laws either. For example, when one colleague used Weinberg's law of raspberry jam (don't spread it too thin) to question why he was writing a sequel to Secrets of Consulting, Weinberg answered with more laws. The law of strawberry jam says that if it has lumps, you can never spread it too thin. The law of grape jam says that if you don't expect much, you're unlikely to be disappointed.

Weinberg bases his consultant's toolkit on the self-esteem toolkit devised by family therapist Virginia Satir, who wrote the foreword to the secrets of consulting. He does this because, in the words of Peter Block, 

The person is the product. Working on becoming a more authentic, whole person is the best business strategy.

The elements of the toolkit come dangerously close to new age superficiality. The wisdom box, the courage stick, the wishing wand, the heart, and others all have a new age sound. Weinberg used his courage stick when he chose this framework. And his wisdom box told him that it would work, because he wouldn't be gift wrapping garbage. He has so much to say and so many instructive stories to tell that any reasonable framework would have served the purpose.

The book is short and hard to summarize. If you're a Gerald Weinberg fan, you don't need me to tell you to buy this book. If you're not, I think you'll find this book a delightful introduction to the man and his work.

The Unified Process Explained by Kendall Scott (Addison Wesley, Boston MA, 2002, 206pp, ISBN 0-201-74204-7, www.aw.com/cseng, $34.99)

In UML Explained (Micro Review May/June, 2001) Kendall Scott explains the unified modeling language (UML), which is at the heart of the unified process. Now he has written a companion volume to describe that process.

The unified process is fairly simple in its essence, but large and complex in its implementation. By omitting material on UML and project management, Scott is able to focus on the core of the process.

The unified process structures software development around five workflows, four development phases, and a large number of deliverables that arise from the workflows and phases. Scott imitates this structure in his book. Using the online bookstore application he developed for UML Explained, he explains the process about as clearly and lucidly as possible.

The unified process is to a certain extent an iterative and incremental approach to development, which inevitably invites comparison with extreme programming (XP). Scott examines the question of whether XP is a special case of the unified process, and decides that it is not.

Like XML and Perl, the unified process has a large body of contributors who continually refine and elaborate it. This short book can give you a roadmap. But if you want to understand the unified process, you must take the next step and use it in a real project. If you are trying to decide whether to use the unified process, this book can help you to make that decision. 

Old Principles

The MIT Guide to Teaching Website Design by Edward Barrett, Deborah Levinson, and Suzana Lisanti (MIT, Cambridge MA, 2001, 114pp, ISBN 0-262-02500-0, mitpress.mit.edu, $22.95)

Edward Barrett teaches in the MIT program in writing and humanistic studies. Deborah Levinson is a graduate of that program who now works as a designer. Suzana Lisanti directs web publishing at MIT. These authors do not focus mainly on engineering; they focus on teaching and communicating. They are skeptical of claims of new paradigms, a digital wonderland, and the death of print. They apply time honored principles to teaching people how to communicate via hypertext-based systems.

Unlike most website design books, this one covers topics like optimal class size and classroom configuration. It emphasizes the need for collaboration, and it focuses on traditional topics like understanding the audience and tailoring the communication to that audience.

If you need to understand or teach website design, you may find this book a lot more helpful than a shelf full of books on HTML or web graphics.