23

Feb

2018

Avoiding Mental Shortcuts When Making Technical Decisions

By: February 23, 2018

The Twelve-Factor App, Agile Processes, Dockerization, MVC, RESTful APIs, Micro Services, lambda functions … the list of the latest technology goes on and on.

The benefits of these technologies and methodologies are highly touted, and rightfully so. Any of them might be appropriate for your given situation, but it's crucial understand WHY a particular solution is beneficial, and how to ensure that you take the time to analyze the tradeoffs that come from adopting one particular approach over another.

On the surface, the need to do this may seem blatantly obvious, but it’s amazing how infrequently organizations make technical decisions in a meaningful and productive way.

Don’t be duped by the brain game

I’m a fan of the National Geographic television program Brain Games. In the show, they demonstrate with colorful examples how the brain functions.

In one episode, they cover the topic of mental shortcuts, in which your brain jumps to conclusions without considering all of the facts in order to save time and energy. Scientists believe that this mechanism is built into our brains to help us respond quickly to danger, but it can also have negative effects. Illusionists often exploit this mental shortcut process in the performance of many of their tricks to dupe their audience.

I’d argue that the mental shortcut process also comes into play for any number of poor decisions that are frequently made in the workplace, whether with respect to technical approaches, organizational processes, or personal work habits.

If you find yourself stuck when trying to solve a difficult problem or on the verge of making a significant decision, it’s a good idea to consciously take a step back and ask yourself whether you’ve taken any mental shortcuts. I’ve personally done this several times recently, with the result being that better solutions were devised than those developed without this extra mental step.

Understand the push and pull of systems

It’s critical to be aware of the nature of the system you are dealing with. At any point in time, a stable system is an equilibrium of multiple competing forces. As one force gains dominance, another diminishes. There is no system where you can significantly change one of the competing forces without impacting others. This is as true in software development as it is in physics or economics.

Just as the iron triangle is a reasonable high level model used by program managers in various fields to conceptualize the trade-offs between schedule, budget, and scope, the model described below can supply more granular insight into trade-offs that impact cross-functional teams making lower level decisions. Though generally applicable, the model is described here in the context of software development.

There are many factors that come into play when developing software. Schedule, cost, and scope can be further broken down and expanded to include factors like time-to-market business needs, long term software maintainability, system scalability, knowledge dissemination, employee satisfaction, etc… The relationship between any two factors may be supplemental or antagonistic. These forces and their interactions can be visualized as axes in a star diagram, where antagonistic forces lie on opposite sides of the graph.

Here's a star chart

Lines have been drawn connecting the dots in the star chart. This line represents stress in the system. The greater the area enclosed by the line, the more stress on the system. You can think of it as a rubber band stretched across push-pins on a bulletin board. The further the rubber band is stretched, the more stress it is under, until ultimately it breaks.

Any factor can be pushed further along its axis without introducing stress into the system as long as antagonistic forces are moved in the opposite direction.

This model only goes so far, but it is useful for helping to check baseless assumptions or unrealistic expectations. Too often, an over-emphasis is placed on one or two factors in the system without considering the impact on other parts of the system. Or worse, there is a mistaken belief that all factors can successfully be moved in positive directions along the axes, which is probably an indication that some factor is not being accounted for. Problems are greatly exacerbated when mental shortcuts are also in play.

It is well worth the time to take stock of the forces and the relationships between them that come into play on any system you are making low level decisions about to ensure that you are not unknowingly causing severe negative impacts in other aspects of your system.

Remember that every decision can impact your product

Writing software is not easy. Many things need to come together to make a software company successful. Low-level decisions that are made on a daily basis often have impacts far beyond our expectations. Being aware of your assumptions when making decisions and understanding the impact of those decisions in the broader context are instrumental in building a successful product.