Simply Accessible’s Agile Coach shares his thoughts about Occam’s and Hanlon’s razors—and how these two discovery tools can help in life, agile practice, and accessibility.

One (just one!) of the great things about my job as Agile Coach is I get to ponder. I like to think of myself as a fairly good ponderer, so I enjoy this work immensely. I’ll see a complex process problem at work and ponder how we can best solve it. Thankfully, in the 21st century, I can access what others have noted about the same ideas and learn from them. Other times, I’ll find something interesting and seemingly unrelated, and then realize we can apply this to our work.

My thoughts on razors are in the second camp.

Occam’s razor is pretty well known, and it’s easy to explain if you aren’t familiar with it. (The Occam part is because it was proposed by a guy named William of Ockham about 700 years ago.) A razor is, in scientific or philosophical terms, a discovery tool—a rule of thumb that can eliminate, or shave off, unlikely explanations.

Occam’s razor can be summed up as: the simplest answer is usually the correct one.

For example, if I hear tires squeal outside, followed by a loud thump, it’s probably not a time-warping Napoleonic army fighting a dinosaur on my front lawn. The noises I’m hearing are much more likely a result of a car accident, and I should respond according to that assumption.

Cutting to the chase

As humans, we seek patterns in our life and work, which is often a very valuable thing. But, we also tend to find patterns when they aren’t there. This is called apophenia, and it can cause problems.

When we rely too much on patterns, we lose sight of the glaring, simple, and obvious answers to things. Occam’s razor reminds us that any problem has a likely cause, and addressing that likely cause will usually remedy the problem.

Hanlon’s razor, lesser known but related, is what I’ve been thinking about most lately. (Again, the Hanlon part is about a guy named Hanlon.)

What Hanlon’s razor states is: we shouldn’t assume malice over neglect, carelessness, or misunderstanding.

Some people add stupidity to that list, but I don’t care for that; it seems negative and not helpful.

When things aren’t going well for us, it’s very easy to assume malice. If we’re frustrated about a problem at work or home, it’s a short leap to convince ourselves that somebody is ruining our efforts on purpose. “My car isn’t fixed yet. Therefore, the mechanic must hate me.”

Almost always, this isn’t the case.

Most likely, the mechanic is waiting on a part, or the fix for your car involves several steps that take time in between, or there’s some other perfectly reasonable explanation. And perhaps due to neglect, or being busy, they forgot to mention this to you. They might have even forgotten that they forgot to mention it!

By removing malice from the thought process, we understand the situation more clearly—which liberates us to make decisions and take actions that remedy the problem.

There’s nothing we can do about a mechanic who actually hates us in the immediate timeframe. There is a lot we can do if we assume they neglected to tell us or we didn’t understand a pertinent detail.

Our frustration turns into a workable action plan: We can call the mechanic and re-establish a timeline. We can ask questions about more details. We can even offer to help. “Is there anything I could do to help the car get fixed?” Often, a willingness to help will show an interest in moving something along, and that alone shifts the momentum.

To translate this into agile terms: you create a shared commitment and establish a positive desire to achieve completion that others take into consideration in their prioritization of activities.

Razor-sharp accessibility for teams

Using these principles may help you get your car fixed faster, but it’ll also help you in everything related to accessibility. For example, the largest accessibility problems we encounter relate directly to complex, over-engineered solutions that haven’t considered the simple approaches to design and development problems that benefit everyone.

When you’re designing widgets or developing web forms, Occam’s razor still holds: the simplest solution is often the best (and most accessible).

Hanlon’s razor holds, too.

On any given day, I work with a dozen different people in different roles who all have their own mandate for success in their jobs. When an organization begins a journey in accessibility, people across teams have to embrace radical changes in the way they work. That can cause a lot of anxiety and friction.

As accessibility advocates, it’s tempting to assume that others are not only apathetic to inclusive design, but perhaps actively looking to block your efforts. However, considering that this may be the first time people have been introduced to accessibility in their work, it’s more productive to assume that a developer isn’t purposefully trying to ruin your web form and block access for people with disabilities. It’s much more likely that she just isn’t aware of the impact of inaccessible code.

On the flip side, a client-side development team might assume an accessibility specialist is making things harder on them than is necessary. That asking them to question the underlying assumptions of their user experience is a cruel waste of time and we should just get about fixing issues. But chances are, that specialist is actually trying to save developers’ time. Thinking about all kinds of users in the design phase removes the need for complex workarounds (which may cause more problems in the long run), repeated remediation, or shoring up inaccessible legacy code.

If you keep Hanlon’s razor top of mind, tensions decrease, and you can quickly form a plan for accessibility awareness and action.

I encourage you to ponder these principles in work and in life—both razors can help avoid unneeded complexity and conflict. Occam’s can help you design and develop simple, accessible users experiences. And Hanlon’s can help you collaborate more smoothly with teams.

Since we tend to repeat what works, you’ll find the more often you assume the likely, and remove malicious intent as a root cause, the load becomes lighter in general. Another bonus is you begin to see relationships in a more positive light, which can make every day better.

And, if you didn’t like this blog post, it’s obviously because you hate me.