Simplest Thing That Could Work

It seems like I have been giving the same piece of advice lately: Start with the simplest thing that could possibly work and only add complication as you need it. Sometimes our natural tendency is to plan for all eventualities. We get so caught up planning for what might happen, that we miss the simple solution that is right in front of us. In both climbing and coding, it is possible to overcomplicate things.

Learn From the Pros

I recently read a book, “The Mountain Guide Manual”. It was quite eye-opening. After climbing for 20 years, I thought I knew it all and had seen it all. I was wrong. It was really interesting to me that as an advanced book, it really stripped everything down to its essence. The book illustrates a lot of really simple techniques. Of course, they all happened in a specific order, and that ordered mattered, but the techniques themselves were simple enough that a beginner climber could easily master them. The difficulty lied not in the individual actions, but in having a plan; in stringing all these small simple steps together to achieve some ultimate goal.

Don’t Get Distracted

Climbers like coders tend to get distracted by the latest shiny objects. My friend Matt calls it the “Magpie Syndrome” -always looking for the latest shiny thing to add to the nest. For climbers, it is having the latest gear, fancy tethers, and the lightest carabiners, or showing off their knot-tying skills with the latest trendy knot. For programmers, it’s about fancy tools and the latest framework. If you want to see the peak of this look at how many different Javascript frameworks there are and how often they go in and out of style.

Stay down to Earth

The classic case of overengineering in programming is the architecture astronaut. This is the person who tries to make their code so flexible, it can adapt to anything. It can be a fun challenge to design such a complicated framework. It all looks pretty and the wires are all straight, but that’s just appearances. There are so many layers of dynamic dispatch that it is impossible to tell what code is actually running. If all that complexity is not needed, it just distracts from the main purpose of the code, makes it harder to read, and introduces more opportunities for bugs.

There’s no new fundamentals

We often forget that the key to being a master is to master the basics. I used to take judo lessons from Kyu Ha Kim. Back when he competed, he had just one basic move, Osoto Gari. It is one of the first moves you learn in judo (after you learn how to fall). He practiced that one move so much, that everyone knew that was his move. He had perfected it so much that they still couldn’t stop him. Instead of learning fancy new techniques, focus on mastering the basics.

7 Comments on “Simplest Thing That Could Work

  1. All of this is true. But just because good architects should be reluctant to make complex solutions, we also need to keep an open mind to recognize when the problem before us really does need a complex solution. Most days, that pile of architecture is just an ivory tower. But some days, it’s a space elevator!

    • Very good thoughts Aristos. Thanks for sharing. I think the trick is finding just the right amount of complexity. The solution needs to be as complex as needed to solve the problem, but ideally no more.

  2. Hi Sam.

    It depends on how you define simple.

    In my situation, and in my organisation, starting with the framework, with the bells and whistles, in my opinion, is the simple solution.

    Are we stripping it down the problem to its most fundamental and simplest implementation – No.

    But are we starting from a position that everyone in our organisation will recognise, with built in debugging, and a tried and tested framework, and starting from a project template that is common across many project, and is ready for growth and extension – Yes.

    In my experience, for our projects, we can’t deliver the stripped down version. It just doesn’t work for us. We rarely get to deliver this stripped down version. It almost always comes back to bite us later if we attempt that.

    • I think that can be appropriate. If you are using a framework and you are using 90% of the features and the other 10% come along for free, I don’t think that is a problem.

      If the ratio is the other way, then I think the framework is probably overkill. If a simple one-button dialog would do, but you built a whole DQMH module for it, I would question that.

Leave a Reply

Your email address will not be published. Required fields are marked *

*