What-if-itis

I've discovered a potentially fatal disease that can severely damage all or some of a software project. Initially it seems benign. You don't notice it at first, since it appears as a helpful set of behaviors: caution, thoughtfulness, building robustness, and many others.

After a while, you notice that your team's ability to decide and produce software has slowly eroded. Before you know it, you have succumb to this disease.

Your team has contracted what-if-itis.

Symptoms
Symptoms include team members introducing scenarios, new technologies, and arguments proposing overly-complex solution to problems that may never occur. Here is an example of how the disease presents.

Someone on the team will (in all sincerity) raise an issue about the application usage. Something like, "What if a customer buys 1,000 different books at once?" Everyone may start out looking around at each other saying, "Wow 1,000 books *would* bog down the shopping cart. We ought to think about pagination, implement some client side caching to avoid server round trips, and..."

Curing Sudden Onsets
Acknowledge the input but gently ask the team, "Is anyone really going to buy 1,000 books?" And if someone did, how frequently would it occur? In other words, yes, this scenario could happen. But is it worth spending precious effort on it?

The easiest and fastest way to rid yourself of a sudden onset of what-if-itis is to get business stakeholders or customers to validate or refute the scenario. Even here you have to be careful. Don't ask if the scenario is possible (it is). Ask:

• How frequently would this scenario occur?
• Under what circumstances?
• What type of user would typically perform this task and towards what goal?

Depending on your relationship with sales, you could also add:

• Would handling this scenario win more sales?
• Would not handling it lose customers?

Once you have answers, you should have a good sense of whether this is worth addressing or not.


Immunizing your team
There are several things you can do to immunize your team:

• Educate
  Educate your team on the domain, the users, and their goals. If the team knows your website is intended to sell books to the general population at a competitive price, then the 1,000 book scenario will be understood immediately as unlikely. Without this knowledge, a team member could legitimately wonder "What if a librarian came along looking to do an annual purchase or to stock a new library?"
• Keep a backlog
  When what-if-itis strikes, "quarantine" it to your project backlog. Your goal is to understand quickly whether the scenario is realistic or not. People often fight for it because they think it will get ignored and cause harm to the product later. Having a backlog assures people that their concern will later be addressed or shown to be outside reasonable system expectations.

The key is to reduce or eliminate the amount of what-if-itis. When it occurs, move quickly to validate it or move it to the backlog. The damage occurs when resources are diverted to researching, designing, and building software for scenarios that may reasonably be considered to be outside normal system usage.

One final consideration. Your market and your customers are the final arbiters of normal system usage. What you may find outside normal system usage may in fact be a very real scenario that your customer faces infrequently, but that you have to handle with elegance. Unless you are highly certain, engage your customers.