Links

In Methods We Trust

October, 1997

This is a draft of an article that appeared in IEEE Computer Vol. 30, No. 10 (Oct. 1997).

In my book Journey of the Software Professional, I examine the critical role the concept of trust has in development teams. Our feelings of trust have a pervasive impact on our performance. We are happier working with people we trust. Bonuses feel great when you trust they are given fairly...and not so great when you suspect they aren't. Communication is easier when trust exists-higher bandwidth, if you will-and far more tolerant of minor mistakes. We feel freer to ask for help, freer to offer it, and freer to act on it. Think about it for a moment. If you can't trust someone during a code review, what are the chances the code review will be any good?

There is another aspect of trust that I've become increasingly aware of: trust (or, more likely, the lack thereof) of a method. (My use of the word method is consistent with Booch, who defines a method as "a disciplined process for generating a set of models that describe various aspects of a software system under development, using some well-defined notation." [Booch 1994, p. 18]. More generally, I think of a method as a disciplined approach to problem solving that will produce one or more well-defined outcomes).

There appear to be two philosophies when it comes to trust and methods. One camp soundly rejects methods as a basis for trust. They believe that the only valid approach to problem solving is to systematically identify specific problems in their environment and solve these problems, one by one. In other words, if people in this camp can't see a specific and direct need to generate a model or follow a process step they don't. Quite often these people reject methods completely.

The other camp takes the opposite approach, performing every process step by preparing all of the models (and other outcomes) defined by their method. Sometimes this is done reluctantly to satisfy corporate police. Other times methods are embraced as a panacea for dealing with all the problems they face ("If I just perform each step, then we'll create the system our customers want!").

So why is this important? Ultimately, all software is built according to some process. It may not be defined or repeatable, as is the theoretical process prescribed by a method, but there is a process. (Indeed, all human problem solving proceeds according to some process and is supported or hindered by some structure). The question is not whether you build software according to a process (you do), but whether you trust the process you have.

In other words, do you trust your development process to generate accurate schedules? Do you trust it to generate high-quality, easily maintainable source code? Do you trust that your process will generate highly usable systems?

Note that trust is not a property of a method or a process, but a relationship you have with the method or process. Perhaps an example might help clarify what I mean. At SmartPatents, we don't have a method for hiring developers, in that we don't rigorously generate a set of models describing each candidate, but we do have a process. And we trust that process (see [Hohmann 1997] for the details of that process).

Interestingly, I've found that asking developers the degree to which they trust their software development process produces a wide variety of answers. Note that I'm not asking if they like it, but if they trust it. My own feelings on this matter are rather complex, but here goes.

1. To blindly assume that the software processes espoused in a book and captured under the name of a method (such as Fusion or Booch) will solve all of your problems is naive at best (but more likely just plain wrong). No book can ever tell you how to deal exactly with the problems in your environment, and few (if any) methods are effective unless they are customized to the specific needs of the team using it.
2. To summarily reject the processes espoused by methodologists ("best practices") is equally wrong. Methodologists have been able to gain a set of experiences that cover a wide range of situations. They have captured, as best they can, these experiences ("lessons learned") in their methods. At the very least, reviewing a method can help you think of questions you might want to ask of yourself to make certain you aren't forgetting anything in your own process.

I tend to side with the methodologists. In other words, I assume that methodologists are smart and experienced people, and that I can usually get more value by simply trying what they recommend rather than inventing everything on my own. I'm not claiming that every methodologist is as smart as every other methodologist! Nor am I claiming that every method is as good as every other method. Of course, even this does not mean that I blindly follow what they say.

Instead, it means that if I'm not certain if a certain process step (such as creating a specific model) called for by a method should be followed I will create it. You might say I tend to trust the method when working in unknown territory. To illustrate, suppose that you asked me to write an embedded, real-time microprocessor control system for an MC68000-based hardware device. Since I've never designed such a system I'd head down to a bookstore and see if I could find a book that described a method for building such systems. I'd read that book, think through the process it proposes, and then try to create the models it prescribes. (In five minutes on the Internet I found about a dozen that sounded promising).

Others may decide that they will only create the models the know they need to create based on their own experience, worrying about other models (or process steps) later. In this respect, they tend to trust themselves when working in unknown territory. I'll leave it to you to assess the relative advantages and disadvantages of each approach.

How do these ideas scale to a team environment, in which most professional software is created? At SmartPatents, we have organized the development group and marketing organization into a set of cohesive feature teams. Each feature team is completely responsible for one or more related product features. Certain horizontal layers providing a core set of "services" to the feature teams. (Not shown are the specific deliverables of the feature teams or the relationship of the different feature teams and development activities to the system architecture).

This arrangement is somewhat common among development organizations that produce commercial software. It is less common among other kinds of development organizations. The key point is that feature teams are given nearly complete latitude in deciding and controlling their own software process.

Feature teams do not solve every problem associated with software development. Indeed, they create some. Consider communication between feature teams. If Feature Team1 chooses Fusion for documenting classes while Feature Team2 chooses Booch, the teams can't share diagrams. This is the primary goal of the Unified Modeling Language (UML): define a common way to communicate information about software/system models, but let individual teams/organizations choose a method of creating and using these models that makes sense to them. Because of this, we have selected the UML as the primary means of documenting models.

By giving feature teams as much latitude as possible in defining their own process, we create an environment that, over time, leads to processes developers can trust. But getting to this trustworthy process is itself complex. If you don't already have a process you trust, how will you create one?

One way to solve this problem is to find someone you trust and ask them what process (or method) they use and then adopt it as your own. Another is take a method that was generally designed for your kind of problem and critically examine it given your situation. Choose the parts that seem to make sense. If you're not sure, plan to try it anyway. You might find the following questions helpful in making your decision. First, does what the method propose help you understand the problem and visualize its solution? Second, does it help others understand your understanding and your solution?

Then, put the process you've chosen into action by following these steps and preparing the models you've selected. When you're finished, you'll have gained personal experience in what works and doesn't work in your environment. More importantly, you'll have gained that much more experience/knowledge on how to make these decisions in the future. Keep track of what works, and what doesn't. It is this kind of track record that forms the foundation of trust.

Of course, examining a method and enacting a new process takes the one thing we never have enough of: time. It takes time (not a lot, but more than nothing) to critically examine a method and make a conscious decision to do something new. It also takes time to enact a new skill long enough to become good at it. And there are no guarantees that the changes you make will actually improve your ability to generate software (although making conscious decisions about your process should help you trust it). Quite simply, choosing to modify your current process in the hopes of generating a more better process requires a leap of faith. (Of course, if you don't think you have the time to make any changes then you must trust your process enough to leave it alone).

Trust is a funny-but important-concept in human relations. We need to learn to trust each other. We also need to learn to trust our process. Rejecting a method simply because you haven't tried it doesn't strike me as very effective. Oh-one last thing. Read through this article, and replace every occurrence of the word 'method' with 'CASE tool'. Get my point?

Acknowledgments

Thanks to James Bach, Clay Miller, Ron Howell, Brent Rosenquist, Russ McClelland, Noura Bashshur, Adam Jackson, and Lori Myers for helpful feedback on an early draft of this article.

References

BOOCH, G. Object-Oriented Analysis and Design with Applications 2d ed. Redwood City, CA: Benjamin/Cummings, 1994.

HOHMANN, L. Journey of the Software Professional: A Sociology of Software Development Englewood Cliffs, NJ: Prentice Hall, 1996.

HOHMANN, L. "The 'Roman Evaluation' and other techniques for hiring the greatest developers" American Programmer Vol. 10., No. 5., pp. 9-12 (May 1997).