Misdirection Anti-Pattern : Solving The Wrong Problem

We looked at an incorrect focus based on faulty data analysis in our prior episode.  This time we explore solving the wrong problem with the misdirection anti-pattern.  While this situation can arise from the data bigotry anti-pattern, it is often a failure to grasp requirements fully.  It is a problem that comes from improper focus and lack of communication.  Those are two prevalent weaknesses in a project that lead to challenges and even failure.

The Misdirection Anti-Pattern Defined

This anti-pattern is simply defined.  We are not solving the correct problem.  Yes, there is a  problem described, and it might even be correctly addressed.  However, it is a red herring of sorts and not what we need to solve to make the customer happy.  Similarly, it may solve the problem but in a completely irrelevant way.  That second situation can make this tough to assess.  Likewise, it can render an entire architecture obsolete or insufficient.

The Anti-Pattern In Action

The misdirection anti-pattern often arises when the focus is on the answer rather than solving a problem.  Thus, we can even pass through QA and testing with flying colors.  We get the correct answer while reaching it incorrectly.  When we "show our work" for the solution, we get a zero for that portion.  Similarly, the incorrect solution will often fail to address outliers adequately and may fail to solve it for all happy paths.

My favorite example is a request from years ago.  We spent weeks working on building a report that could display hundreds of thousands of rows in a reasonable amount of time.  The query result set was huge, and even paging was slow.  They needed the whole report but only cared about the last page.  That is where the misdirection anti-pattern became apparent.  The actual goal was to get a count of records.  The details of each record were not helpful in this situation.  Thus, the query only needed a summary and not all of that detail.  Unfortunately, this is not at all uncommon.  There are many examples of reports and results with a lot of detail that is often ignored.  The wrong problem was solved.  Therefore, the summary data provides the answer, while the details are extra work that is not needed.

 

Avoiding The Anti-Pattern

There is a useful method architects use to gather requirements.  They follow each answer to a requirement by, "and then what?"  That approach helps us avoid this anti-pattern.  It requires a solid understanding of the problem and also its context.  We can not ask about pain points and then jump right to relieve those.  Instead, have a conversation around the issues and obstacles that highlights the various options available.  This process includes suggesting a couple of solution approaches to determine whether the pain point is the source of the problem.  It is like a doctor that asks a patient what hurts, and instead of addressing the hurt, they dig to find its source.