john coder

Preface

This post discusses a process that emerged from the small team of two developers that I work on. Steven Hook is the other developer, whom I've known since college. We've been good friends outside of work, and design various aspects of software on a near daily basis.

Our working environment is somewhat unique; no product manager or QA to speak of. Generally speaking, we're given little guidance on requirements or desired features. This situation requires us to wear a lot of different hats, from UX designer to software architect. Rather than impose a formal process on such a small team, we let ourselves arrive at a process that works for us. One that stays out of our way, and lets us do what we need to do: design and implement software.

This process isn't geared toward anyone but the small team I work on. Take from it what you will.

What's in a Name, Anyway?

All processes have to have a name. "Differential Design" is the name I've been using to describe it to others. The structure of the process resembles that of a differential diagnosis.

Differential diagnosis is a method by which doctors start with a list of symptoms, and arrive at a correct diagnosis by process of elimination. The diagnoses begin as simple as possible, gradually becoming more complicated as they're ruled out. This is the collaborative paradigm of our process.

Following a trail of links, you might stumble onto the wikipedia entry for the Hypothetico-deductive model. This model is what will drive the process toward the best design. Consider this excerpt from the article:

"According to [the Hypothetico-deductive model], scientific inquiry proceeds by formulating a hypothesis in a form that could conceivably be falsified by a test on observable data. A test that could and does run contrary to predictions of the hypothesis is taken as a falsification of the hypothesis. A test that could but does not run contrary to the hypothesis corroborates the theory. It is then proposed to compare the explanatory value of competing hypotheses by testing how stringently they are corroborated by their predictions."

This demonstrates the more scientific aspect of our process. Basically, test theories to figure out how they work toward solving the problem at hand. Then, take the results and compare them to other available solutions.

For the rest of the post, I'll refer to the "Differential Design" process as "DDx."

This is strictly anecdotal, but I attribute a lot of this process to House, M.D. I'm a big fan of the series, and having seen many differentials performed on the show, I started to notice similarities in how my team worked, and how House's team worked. Naturally there's less narcissism and insults flying around, but the process is largely the same. The goal is to arrive at a conclusion, and we're all there to make it happen.

Process Format

The format of our process is somewhat informal (mostly because it's just something we do). Here's a basic outline of what happens during DDx:

1. Define Success Criteria
2. Suppose a Candidate Solution
3. Determine Pros and Cons
4. Justify Pros and Cons with Rationalizations
5. Repeat Steps 2-4 (as necessary to gather a sufficient selection of candidate solutions)
6. Sandbox Candidate Solutions (to provide further evidence of feasibility)
7. Consider All Candidate Solutions (weigh pros and cons against success criteria)
8. Implement Least Objectionable Solution

The following sections expand on each of the steps listed above.

1. Define Success Criteria

This is a fairly simple step. As a group, brainstorm a list of conditions that constitute a favorable solution. Items on this list can be anything, from a must have to a nice to have. Here are some examples: In a UX, you might look for one or two happy-path scenarios, where a user can perform an action in the least possible amount of clicks. In an API, you might require a happy-path scenario of instantiating a class with sensible defaults, allowing a user of the API to do a specific task in the fewest number of lines of code as possible.

2. Suppose a Candidate Solution

As a group, take turns suggesting solutions to the problem. These solutions may cater to any number of the success criterion (but more is better than less). No solution is too silly to suggest. Always use everything at your disposal to come up with candidate solutions: past experiences, recently read articles, and an ocean of buzzwords. Google/Bing is also a great tool. Do a brief search to see what others are doing to solve the problem at hand. This is an excellent opportunity to explore nontraditional solutions, like CQRS and NoSql. This process gives them a fair chance to weigh in against tried and true approaches.

3. Determine Pros and Cons

Given a candidate solution, enumerate pros and cons based on the merits of the solution itself, as well as compared to the success criteria. This should be collaborative and objective. Each participant of the DDx is likely to have a slightly different perspective, which naturally leads to a strong list of pros and cons.

4. Justify Pros and Cons with Rationalizations

This step is important. Each of the pros and cons should be scrutinized carefully. They may only stay on the list if presented with a strong rationalization. Lack of rationality is grounds for elimination. Remember to be objective, and welcome input from all participants.

5. Repeat Steps 2-4

This is just our idea loop. Steps 2-4 are about generating well thought out candidate solutions. You can always return to this step later in the DDx if other options should prove to be fruitless. Bear in mind that you could also circle back to the same problem in another DDx session altogether!

6. Sandbox Candidate Solutions

Sometimes an idea is hard to imagine, making it difficult to enumerate the full list of pros and cons. In this context, sandbox can mean lots of things. The participants can collaborate on a common medium, such as a whiteboard. Or, they can break off to create a proof of concept for a candidate solution. This should be kept as small in scope as possible. More involved sandboxing endeavors tend to be great pairing exercises. Writing unit tests is a great way to sandbox candidate solutions.

7. Consider All Candidate Solutions

The pros and cons of each solution need to be weighed. Some solutions are better than others, and usually for drastically different reasons. This analysis is really where the DDx becomes exciting. Each participant needs to be an advocate for the success criteria, because the goal is to choose a solution to implement. Choices are difficult, which is why the result of this step should be known as the Least Objectionable Solution. Choose the solution that best meets all of the success criteria.

An odd outcome that happens often is the combination of candidate solutions. Sometimes two candidate solutions are both complementary and compatible. That is to say, you can implement both to get the benefits of either solution, while effectively cancelling out the disadvantages of either solution. Repeat the earlier steps of the process on this newly formed idea. This is a great technique for getting some truly unique ideas on the table.

8. Implement Least Objectionable Solution

Take the selection from the previous step, and implement it. Occasionally, the selected solution ends up being the wrong one for unforeseen reasons. When that happens, start another DDx (either picking up where you left off, or with a completely new one).

If the implementation is deeply committed, a new DDx should include that as a constraint. Working within the parameters is the name of the game. New ideas should work to alleviate problems with the current implementation in order to meet the impending deadline.

ASIDE: The Least Objectionable Solution term pays homage to Dr. Sheldon Cooper's "Friendship Algorithm" in the Big Bang Theory (to which this entire process has a strong corollary):

(credit: above image from http://bigbangtheory.wikia.com/wiki/The_Friendship_Algorithm)

DDx in Practice

So far I've painted a picture of a methodical process, with meticulous intricacies and rules of operation. Sorry. It's really very simple. I can reduce all of the above down to the following: "Have a conversation about what you need to do." Conversations move in two directions, and conversations about decisions generally have outcomes. That's all you really need to know. All of this rhetoric is just a formalization of something that can happen very organically (and often does).

Starting out with this process, your team is likely to follow the set steps. Eventually, it will evolve in to a conversation under fire. Everyone understands the rules and goal of the DDx, which lets the whole team move from solution to solution very quickly.

Other Things to Consider

Q: How does this affect design?

A: Expedience and quality. When tasked with designing and implementing features individually, Steve and I tend to do a really great job solving most of the problem at hand. Upon demonstrating progress to one another, we generally expose a lot of gaps in the solution. The DDx process gives us a chance to put our minds together to shorten that feedback cycle. The shortened cycle makes it quicker overall.

Q: How long is a typical DDx?

A: As long as it needs to be. Some sessions are brief, lasting only 15 to 20 minutes. More complicated success criteria can draw out a DDx over the course of a few hours, even spanning several sessions. It may help to break down success criteria into smaller pieces for shorter DDx sessions.

Q: Who is DDx for? Designers, developers, or architects? Somebody else?

A: Everyone. As I said earlier, I wear a lot of hats at my job. I find that no topic is too small for DDx. My team often uses it for designing user interfaces, from functionality to font sizes. DDx has also been great for connecting our architectural dots. Web application here, windows service there, connected by an API, all talking to a centralized database and denormalized to a reporting database. Which solution works the best is the perfect topic for DDx. The process isn't limited to design, either. We often employ these same tactics for troubleshooting and resolving issues.

Q: How do we keep from offending one another during DDx sessions?

A: It's all in the team dynamics. All of the participants really need to have mutual respect and understanding. The key to progress in DDx is keeping a favorable argumentative-to-abrasive ratio. Argumentative by definition is good; "Using or characterized by systematic reasoning." Abrasive is bad. Reject ideas, not people.

Try to weigh each idea equally, and disregard who originates the idea. Objectivity and rationalization will help mitigate animosity. A common source of animosity is appeal to probability. That is to say, someone deems a solution "feels wrong" will inevitably conclude that it is wrong. When that is the case, ask each DDx participant to try and come up with concrete evidence that is contrary to the desired outcome. It is actually wrong if there is a sound reason.

Q: What do you produce during a DDx? A spec? A napkin diagram? Wile E. Coyote grade blueprint?

A: Whatever you need to get the job done. Typically, our DDx sessions result in a diagram on a whiteboard that stays there until enough progress is made to continue on. Other times a to-do list, or a short written summary. Often enough, the solution is "as simple as possible, but not simpler." On rare occasions, a few page spec has been produced.

Conclusion

Over the course of this long post I've detailed the process that my coworker, Steve Hook, and I use to design software every day. The process is not nearly this formal. The steps I detailed out are merely a foundation for using DDx to design software as a team. I'm interested in what others think of our methods, and perhaps how it applies outside of our somewhat unique development environment.