Letter to reviewers

Dear reviewer,

The "Outside-In" title took some time

This book has a problem in that it covers a conjoined design and analysis process. The word design had a problem in many software development contexts in that it refers to the stuff developers do in code. Many functioning as business analysts see "design" as the responsibility of developers. However, good business analysts not only describe the world as it is, but help envision the world as it might be with a new piece of software in it. Envisioning this new world is what I'll call design - and coincidentally what the User Centered Design community calls design.

In short strokes the title couldn't have the word "design" in it - because it confuses people. It couldn't be a book about User Centered Design - because those books have a limited audience and just don't sell well. And, it couldn't be a book about requirements, because I'm allergic to the term and it just isn't appropriate for the work we're doing, especially in an agile context.

Outside-in refers to the way we think about and design software. It took some time to arrive at that title. The idea is we start with business objectives, through to users and their goals, on to the way they might use software to reach their goals, then to the way the software might look and behave. We'll finally end up with something to build. I see this as working outside in. Development processes that start with what to build are inside out.

This book targets the quietly frustrated

Around 2000 Beck's, Extreme Programming Explained hit the market. Prior to the introduction of that book there were a large number of programmers working in quiet, and sometimes not so quiet, frustration. They knew the best practices they were asked to follow weren't working. When software design and development didn't go well, they were blamed, or made to feel guilty by others or themselves for not following those suspect best practices. XP gave that group of programmers a set of better practices they could stand behind. It liberated, or gave permission to, hundreds of thousands of developers to work in a way that they felt good about.

On the other side of software development are those that don't write code. This includes business people who need software to solve problems, business analysts who capture, decompose, and manage requirements, and testers who identify issues in the software we build. For this group as well there are many working in quiet, and not so quiet, frustration. They also have best practices for capturing and documenting requirements for the software they need; And, they attempt to follow these practices knowing that they don't work well. Or in some cases they defy management to attempt approaches that allow them to work in a way they feel good about.

This book is for that group of people. For those who know in their heart that successful software starts with choices we make about what to build. They know that these decisions are made, evaluated, and reevaluated continuously throughout the design and development process. They know that the process of eliciting, documenting, and managing requirements often acts as an encumbrance to that real goal of building software that is really valuable to both the business that pay for the software and the people that use it. They know there's much more to it than writing down what people ask for.

My goal would be for this book to act as a tipping point for people on the requirements side of the software to see their role and their practices differently just as XP acted as a tipping point for those on the development side.

That's a big goal.

I expect those quietly frustrated to first pick up the book. I expect them to read it, talk about it, and adopt practices. I have hopes that they'll recommend the book to those that don't normally buy books… those that may not be concerned enough about their work to be frustrated, but wouldn't mind being a bit better at it.

There's a secondary audience of people who do see user requirements differently. In fact they refer to themselves using the controversial word "designer." In software development designer is a word usually reserved for developers and architects who design solutions to problems using code. But, user centered designers, interaction designers, and visual designers, while they don't always design in code exercise creativity and innovation to do their work. They study the subject of their design problem, their users, with expertise and efficiency applying many proven techniques to the task. They leverage that information to design innovative solutions to their users' problems.

But, in many software development environments, this group also functions in quiet, and not so quiet, frustration. They're often outnumbered by those that believe requirements are captured, not designed. They're often invited to the table late, when many important design decisions have already made such as what the software should be doing for its users and how. They're often asked to make those decisions look good by designing user interface that looks pretty, by putting lipstick on the pig.

This book is for those in the user centered design field who know there are better ways to make decisions about what software to build and what it should do, but can't find a place in their current software process or peers to collaborate with to share that important design work.

This book distills existing work

The book intends to support its reader tactically. By that I mean to give very specific advice on what to do in their job today. Its intent is to distill a wealth of emergent best practices into short step by step instructions for building models and employing techniques. Each of the techniques described here are distilled directly from or built combining other well documented techniques. The sources for the more exhaustive discussion will be referenced along with each model or technique in a "further reading" section. In many cases further reading will add foundation around a specific model or approach, but it's important to note that the specific way in which this book suggests you collaboratively practice a technique may be very different than the way the techniques creator originally envisioned it.

What you can't evaluate today is how this book looks

You'll have to use your imagination. So close your eyes and imagine a thin book, something thin enough to easily slip into the bag with your laptop. Actually, wait till you've read the entire section before closing your eyes.

When you flip open the book it's clear what Part of the book you're in and where in that part you are. The start of each part is marked by a a color that bleeds to the edge of the page, so to find the beginning of the part, you could look to the edge of the book and use your thumbnail to navigate.

The start of each part gives a mini table of contents saying what's in the part, and page numbers for each technique in the part. Symbols let me know if this is a collaborative technique, a model, or a foundational technique used by other techniques.

Flipping to a technique you find that it always starts on the top of a right hand page of the book. The technique has an evocative name that helps you remember it and easily imagine what the technique is. Techniques that are hands-on are illustrated with pictures at many of the steps. Sometimes the pictures are photos, but more often they're illustrations that clearly show people, or the hands of people doing things. The simple line drawings, layout, and presentation remind you of Cooks Illustrated Magazine, a magazine that not only gives you recipes but illustrates any tricky techniques described in the recipes, warns you about common problems you might have making this recipe, and gives some background that tells you why you might want to make the recipe in the first place. Using the techniques in this book is as easily as following a recipe. And when following the recipe formatted this way, it makes you more interested in "cooking" - metaphorically speaking.

You'd carry this book with you often. It's easy to navigate, easy to reference when attempting a technique. You've found that to help someone else out with one of these techniques it's easy to flop the book on a copy machine, and photocopy the technique.

In your current role you've found some techniques more valuable than others. You've used the "further reading" section to locate other books or articles that help you explore a technique more deeply.

This is one of your favorite software development books.

You'll find four kinds of content in this book

Concepts explain ideas you'll need you'll need to understand to participate in an outside-in development process.

Techniques leverage these concepts to create or evaluate models and artifacts usually in a collaborative way.

Foundation techniques are cross-cutting techniques used throughout to support the collaborative work typical of an Agile environment, and critical to my personal design and development philosophy.

*Glue" is the name I give the other pages that hold things together - sort of like mortar in a brick wall. You'll likely find places where there's not enough glue, and bricks rub together or you can see through the wall.

Final Comments to Reviewers

What I'm most looking for in way of feedback right now is:

1. Is the book becoming coherent: does its structure make senses?
2. Good points about the writing style: what in particular works well for you? - helps you quickly and easily understand the material being discussed? This book needs to be distilled. What might help compress the content?
3. Things to eliminate or ideas for improving the writing style: what types of discussion or approaches to describing a technique aren't working? Do you have any suggestions to improve them?

Thank you reader for reading what exists so far. I understand now more than ever that a book is a collaborative effort. When I open a book these days, I tend to go strait to the acknowledgements section early in the book to see who helped. I think the quality of the collaborators has much to say about the quality of the resulting work.