Reducing Modality

While there is a never ending supply of beginner guides and information out there, there is much less information about the skills you need to become a mid level Programer. To hopefully address this I want to break down a couple of concepts that helped me become a much better Engineer.

Defining modality

For our purposes here we will define modality as a particular mode in which an application operates under. This can be a simple as a code branch or as complex as running on different CPU architectures.

Between modes an application will behave differently, To an extent this is desired, while you can make a fart app without much modality, not much more could be built.

But as with many things modality is best had in moderation.

Why less modality is good

While modality is necessary there is a cost. For each mode your application can run in you have more possible points of failure. To make matters worse, this is exponential. So adding that 5th branch or option, means you go from 256 to 3125 possible modes your application may work under.

Now we can reasonably say that not all modes will interact with each other, but knowing when that is the case is the cause of many a Programers frustrations and the cause of many of outages.

This becomes more impactful if these modes are obscure or rarely used.

A recent high profile example of why modality can cause problems is with Log4j. In this case log4J had a Mode where it would in some cases process string sent to it using JNDI. The exact details are not relevant, but this mode was obscure and such went unknown for years before being exploited. What we can learn from this is that even adding a new mode of any type can have unexpected ramifications.

While in Log4J's case there was other failings that cause the issue to be so bad, we can still lean that adding any new mode adds risk.

What can you take from this

Many Programing principles exist directly to reduce modality or the obscurity of those modes. So the good news is that this complements them, but is a new thing to be thinking about as you design and build applications.

  • Apply the Single responsibility Principle
  • Apply the Dry Principle (as in to not repeat logic)
  • Avoid and remove rarely used modes
  • Avoid Injection
  • Avoid Inheritance
  • Use automated tested to test though these possible modes

i