The pros and cons technique is a way of comparing proposed solutions to a problem. It forces you to think through the implications of each solution and increases your understanding of the solution. (Incidentally, I am sure that this technique has a much better name than “pros and cons”, and that someone else has written about it in greater depth – if anyone knows of any good references please post them in the comments).

The technique consists of two steps:

1. For each proposed solution make a list of all advantages and disadvantages, however (apparently) trivial.
2. Weight the advantages and disadvantages and use that information to inform your decision.

Step #1 involves intellectual honesty. Even if you have a preference for a given solution you should consider yourself honour-bound to come up with all the reasons to oppose your preferred solution (consider it similar to preparing for a debate – you should be able to argue your opponents case as well as you can argue your own).

Typical things that might appear on the pros and cons lists for a proposed solution include:

• How easy is it to convert from the problem statement to the code?
• How easy is it to covert from the code to the problem statement?
• How easy is it to modify the code in the future?
• Does it keep the code together?
• Does it split things into separate functions?
• How easy is it to debug?
• How comprehensible are the error messages?
• How close is it to the standard language or common idioms?
• Does it use compiler specific extensions?
• Does it add extra levels of nesting?
• How much typing / boilerplate does it involve?
• Does it pollute the global namespace?
• Does it use deprecated features?
• Is it consistent with existing code?

There are many more, some of which inevitably will be project specific.

Several of these items can appear both in the pros and the cons lists – those are often the interesting items that show up particularly important areas that need to be carefully explored. Often some of the entries on the list contradict each other – that’s an opportunity to look for the balance between opposing forces.

Sometimes coming up with an absolute pro or con (or an absolute weighting) is difficult. In that case it is useful to compare solutions against each other and see how much better or worse one of them is in a particular area.

Step #2 does not involve assigning numerical weights, adding them all up and picking “the winner” (at least it never has in my experience). Notice that it states “use that information to inform your decision”. This isn’t a short cut or a mechanical process, it’s a way of learning more about the problems and potential solutions.

In practice I have found that step #2 ends up identifying the key factors that matter to your company, project or team. Those factors are often different between different projects, and can vary over time on the same project. For example, I was on a project at Adobe that supplied libraries to After Effects and Photoshop. “Don’t pollute the global namespace” was a hard and fast rule. There were a couple of times when we had to break that rule – we had a very small number of macros in public header files. With the macros we used a poor man’s namespacing and put the name of the project at the beginning of each macro name. On other projects we controlled everything in the project so we didn’t worry about polluting the global namespace (although in a couple of cases we should really have done some namespacing to help with the internal organization).

Even if the right solution is relatively clear I think it is still important to know what the disadvantages of that solution are. If you don’t know what the drawbacks are you won’t be able to mitigate them (as with the macro name’s “poor man’s namespacing” I mentioned above) and if you don’t know the drawbacks you don’t have a full understanding of the solution.

Years ago I read an interview with a woman who was the secretary for the original UNIX team (I do not have a cite for this – if anyone has any details please let me know). One of her tasks was taking notes during design meetings. The interviewer asked her a very perceptive question – “what was the most useful information you recorded during those meetings?”. Her equally perceptive answer – “the reasons why we didn’t do something”. Let’s face it, if there is any documentation at all about the design process it will focus on the solutions that were used, not the ones that were discarded, yet I have been in many meetings where we tried to remember why a particular solution wasn’t chosen. It might have been dismissed for the right reasons, or the wrong reasons, or the right reasons at the time but the situation has changed so that those reasons no longer apply. Pros and cons gives a format where at least some of those reasons can be recorded – even if it is just via an email discussion or  in the comments of a task or bug tracker.