This website introduces the AZ Problem: a generalization of the XY Problem. To wit, if we agree that the XY Problem is a problem, than the AZ Problem is a metaproblem. And while the XY Problem is often technical, the AZ Problem is procedural.

The AZ Problem is when business requirements are misunderstood or decontextualized. These requirements end up being the root cause of brittle, ill-suited, or frivolous features. An AZ Problem will often give rise to several XY Problems. Some telltale signs of an AZ Problem waiting to happen:


  1. Customer requests new feature: accumulated fees should be emailed once a month.
  2. Account manager agrees. Suggests the last day of the month.
  3. Customer is indifferent. Last day of month is just as good as first day of month.
  4. AM passes feature request to Product Manager: send accumulated fees on last day of month.
  5. PM passes request to developers.
  6. Developers spend time solving a harder problem than they have to.

If you're wondering why the problem is much harder than it ought to be, we only need to consider the pseudocode for sending emails.

Code that sends email at beginning of month:

if day_of_month is 1:

Code that sends email at end of month:

if day_of_month is 31 and month in [ 'jan', 'march', 'may', 'july', 'aug', 'oct', 'dec' ]:
if day_of_month is 30 and month in [ 'apr', 'jun', 'sep', 'nov' ]:
if day_of_month is 28 and month in [ 'feb' ] and not leap_year:
if day_of_month is 29 and month in [ 'feb' ] and leap_year:

Obviously not only is the latter more time-consuming to write, it's more bug-prone and more dangerous to deploy. The developers could have avoided releasing this code — instead opting for the much more straightforward version — had they known that the customer was indifferent to the exact day of the month when the email should be sent.

What to do about it?

About this website

This website was made by David Titarenco using mincss and Atom.