Doing it the right way: Asking "why am I doing this?"

It's a simple question: "why am I doing this?"  Unfortunately, too often we forget to ask ourselves why we are doing something. In marketing/advertising, some people call it the "so what?" test. I've heard a tech colleague call it the "stupid test" -- but call it whatever you want, it just doesn't get asked enough. Below are a few of my favorite patterns of this:

The Builder

I love hard-core tech people. The sorts of people who have deep, intellectual and detailed technical debates like this one on SOAP vs. REST. The kind of people who just live to build things with technology. Often these people take overly complicated routes to doing something just because they can. At times, I am one of these people. For example, I want to do this so my tomato plants stay healthy this summer.  Just because it is fun does not mean its the right thing to do.

Even if it takes very little time, building the wrong thing can be very expensive over the life of what you're building, so make sure you know why it's there in the first place and make sure there isn't a more efficient way to get it done before you start.

The Template

Templates are wonderful. Patterns are great. But they don't always fit every problem. Before you use a pattern, ask what part is relevant to the task at hand. What outcome do you want to drive? What risks exist? Quantify them and make a decision about what part to use and what not to. Here are a few common examples of the productivity-killing template:

• The software document that someone filled out instead of authored. It has all the fields filled in, its umpteen pages, but its not useful to its audience.
• The form that asks several questions but never seems to hit the core issue.
• The software process that includes steps that do not create any value or reduce any risk in your scenario.
  
• The software package/library/API that you chose too quickly yet doesn't fit what the business needs.

We can't always control the template, but we can apply common sense. Keeping in mind why it exists, who will use it and what the real purpose is (which may not be obvious) can mean a big boost in effectiveness.

The Review

I am very particular about code reviews. If done properly, they can be incredibly effective in removing defects. Unfortunately, most code reviews are not done properly.  The problem isn't limited to code reviews. Security audits, requirement or prototype reviews, software package selection can all fall into the trap where we focus only on what is top of mind rather than the core purpose.

Too many code reviews focus on items of little value to anyone or, worse, on trivial debates about spacing or naming.  Security audits can focus on compromises or breeches that have little quantifiable cost to the business, leaving more significant risks untested.  Business reviews of requirements too often focus on what is top of mind rather than what is most critical to resolve early.

It is amazing what we can accomplish when we step back and take an orderly and rigorous approach to solving the problem at hand. Review the code to remove defects. Review the requirements to understand the limitations. Audit the software to understand risk to the business.

Best Practice?  Not if you're doing it wrong.

Occasionally it is tempting to just stop building anything. Don't write any documents. Don't have templates for IT requests, forms for employee reviews, requirements documents or code reviews. After all, if it doesn't work, why do it?

Because if you have more than a handful of people at your company, then you do need process. Lots of them, probably. You need forms and checklists and reviews to make sure that risk is adequately controlled, people remain productive and things keep running even when the really smart key people aren't there. Most importantly, you need to adapt and adjust those processes to be more efficient by having everyone on the team asking why and contributing to making the whole system run more effectively.

...and luckily, it costs almost nothing.