Misdirection Anti-Pattern : Solving The Wrong Problem

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.

 

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.