So one time, I showed a friend a Web site for a project I was working on. And he asked an interesting question:

Well, you're design guy right? Shouldn't you be writing a design document?

And what I suddenly realized was unclear was that the Web site was a design document. It was just a design document of a very different sort. It was basically a step one design document, serving as a way to put the ideas in a concrete form for discussion. The team kinda knew what the product should do, but not every last detail yet. Some team members were ready to jump in and start coding right away, and just call it Agile Development if we needed to justify the work. Instead we said, "Wait a minute. We have a vision, but no details. If we don't explore what some of the users will demand from the system, we won't design the architecture to accommodate them properly. So before we can write a line of code, we need to explore what a range of users need. Then we can design an extensible architecture that should support most of those needs. And then we can jump in and start coding." So the Web site was, in part, a format for exploring what different sorts of users would want, by telling stories of how they would use the system. And since the system was intended to be marketed to users who could use those same stories as a way to envision using the system themselves, it made sense to document those stories in a marketing-oriented Web site. But marketing-oriented or not, the Web site still served a purpose as a design document.

Now my friend would never be so rigid and unimaginative as to say that the Web site wasn't a design document; but I have met people who are so wedded to hidebound procedures that they would have argued exactly that, just because it didn't conform to some formally defined design document template or fit into some formally defined design methodology. And that reminded me of Kipling:

"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

Design is a heuristic problem, meaning that there are techniques that can lead to a solution, but no single guaranteed and inviolable path to a solution. Quoting from Wikipedia:

In computer science, a heuristic is a technique designed to solve a problem that ignores whether the solution can be proven to be correct, but which usually produces a good solution or solves a simpler problem that contains or intersects with the solution of the more complex problem.

Note the word "usually" in that description. Some heuristics are better than others, but none can be proven to be right, especially not in the general case.

There are many ways to design, because design is really just a means of communicating and refining your ideas. Different people communicate better in different fashions. Some people are more visual, and some or more verbal. Some are more instinctive, and some are more methodical. Some are more detailed, and some have a broader view. And so there's no one right way to communicate a design to other team members and stakeholders. The only "right" approach is multiple approaches, to ensure that you cover the same material in different ways to gain different perspectives.

As an example, some people love written design docs, and just can't see any benefit in design diagrams. Others believe in making excruciatingly detailed UML diagrams, and sometimes see those as "complete" designs. Now I'm pretty fanatical about using UML for my designs; but when I teach UML, I always point out that neither text nor pictures is sufficient. You need both. Different people and different teams will emphasize one over the other, but you need both.

That doesn't mean that there aren't better ways and worse ways to design. I would never consider a marketing-oriented Web site to be a complete design, just a step in building the design. But when we built that Web site, we were definitely participating in a design effort. Because...

"There are nine and sixty ways of constructing tribal lays,
"And-every-single-one-of-them-is-right!"

As an author, it's always nice when someone says they enjoyed your book.

Nice? Heck, it's incredible.

But last night at CMAP, Dr. Osama A. Morad, Ph.D. gave me a compliment I will not soon forget. Upon meeting me, the first thing he said was, "Hello, Martin. I read your book. How's Sandy?" And then he told me how much he appreciated the dedication to my book, reproduced here:

To Dad, for teaching me how to work.
To Mother, for teaching me how to think.
To Sandy, for teaching me how to be me.

I can't speak for other authors, but I worked hard on that dedication, to get it to say exactly what I wanted to say about the three biggest influences in my life. For Dr. Morad to recognize that was really special, and is the nicest of the many nice things that readers have said to me. (He also asked some other good questions about the book, proving that he did indeed get farther than the dedication.)

Sandy's not in my book (computers don't need feeding or walking or grooming, so they don't interest her); but like everything I do, Sandy's all throughout my book. I'm the person I am because she helped me to open up to the world on a personal level. Before I met her, I was a geek. Because I got to know her, I'm a geek who knows how to relate to people and reach out to them and communicate with them a lot better. Growing up, I was an introvert by nature. I still have a self-image of an introvert; but I also know that self-image is inaccurate, because my whole job now is about standing up in front of students and conference attendees and trying to share ideas with them. And an awful lot of that I learned through interacting with her. Sandy is comfortable in many different social situations and groups; and because she drew me into them with her, I became more at ease with them.

That's just one of the many ways Sandy makes me feel somehow more me (if that makes any sense), but it's the one that's most relevant to the book and to my teaching and speaking.

And there's one other way in which Sandy was key to the book: my sample project for the book (and for my UML classes) is an information management system for a high-end pet kennel. Everything I know about pet kennel management comes from Sandy's years in that business.

So I really have to thank Dr. Morad for the kind words, and the chance to acknowledge a little more fully Sandy's role in creating the book.

We're working on a Boston session of our UML BootCamp. Stay tuned for details.