Year of the Occam

How to get to the simplest solution in whatever you are building

What was your first portable music player? The answer to this question will definitely age you. For me it was a personal cassette player, but not the cool one from Sony. After a brief time with clunky portable CD players, I quickly jumped onto MP3 players.

It was early days and design aesthetics did not seem so important. It was all about the features, and the one I had from iRiver was the Swiss Army knife of players. It played MP3 files, but it did so much more. It had a high-res display, FM radio tuner, a note taker, and voice recorder.

At the time, the first generation iPod came out. It was slick and clean looking, but functionality wise it was pretty mediocre. With the release of the iTunes Store however, the value of the iPod changed from just another MP3 player to a music ecosystem. Apple took what was the most painful part of the MP3 process, ripping CD’s and loading files, into a seamless experience for any level of user. They won the complexity war not with more features, but with simplicity.

My recent post about building MVP’s provoked some interesting questions touching on the topic of complexity. In response to my statement that an MVP should only focus on what is of value to a user, someone asked, “What if that requires you to create at least 80% of the product?”

My response was that you probably do not even know what 80% complete of a product looks like. A better response would make the point that your users don’t even know what a complete product looks like. That was certainly true of the iPod. The bet was that users wanted something that was less of a gadget and more of a lifestyle.

In the developer world, we talk a good game about simplicity. We mention clean code, have various naming and formatting conventions, and speak at length about the art of finding elegant solutions. But the reality is that most code is the opposite of elegant and more like some monstrous Spaghetti O’s pie from this video:

Developers often cannot be blamed. Engineering involves many compromises pitting speed versus time. This is the root cause for most of the technical debt that accrues in products. Developers would prefer to build more robust and streamlined code, but sprints and impending deadlines force one to use shortcuts and hacks just to get workable code shipped.

Then again, the creative aspects of coding can lead to mind boggling complexity. There are even contests dedicated to the art of code obfuscation. Without even the impetus of a competition though, developers will sometimes purposefully proceed down the path of the most complex solution.

You might think I am wrong. But then you would have to explain the popularity of Kubernetes or why some developers insist on using a bleeding edge language when the one the team already knows would suffice and ensure timely delivery. Sometimes, like in the Telephone game, I have seen features described in the design stage only to look and do something completely different after it was built. The engineering team would then proudly declare they improved the feature.

One of the ways I have learned over time to help simplify complex situations is a tool many know called Occam’s Razor. Also known as the law of parsimony, this is a problem-solving principle that states the simplest explanation is usually the right one. In the way I use Occam’s Razor, it can also be stated as the simplest solution is usually the best one.

For example, if I am building a website for my startup, there are a myriad of choices to creating the basic company website. My default approach for years was to stand up a WordPress site and find a free single page template to customize. Some more technically minded startup founders however would opt to custom code their sites on headless CMS platforms.

As soon as those founders bring on their first marketing hire, the first thing to go is the custom built website. Why? Because building a static website that requires code in order to change makes it impossible for anyone non-technical to make changes, slowing down marketing.

This is the point AWS often makes about undifferentiated heavy lifting. You can build your own data center. You can maintain racks of servers. You could build machine learning frameworks on Pytorch or TensorFlow. You can do everything from scratch, but why would you when it is easier and more cost effective to setup instances on AWS and use SageMaker Studio for managing and training machine learning models.

An argument can sometimes be made though that the simplest solution is not the ideal choice. Take integrations for example. You can integrate one system, like a payments gateway. Then soon after there is a request to build another, and then a third. If you build each of these integrations separately, it becomes a maintenance and support nightmare later on.

A more sensible approach than building one-off integrations is to use abstractions. Creating a common interface that allows multiple of the most common systems to integrate is the most optimal solution, even if that means more upfront complexity and longer development.

Decision heuristics in this case and other similar examples adds a time consideration. The best solution is not merely the simplest solution. The best solution is simple and can stand the test of time so that the overall objective is achieved faster.

The question of what to build in an MVP is a balance between complexity and simplicity. The tendency to overbuild and overengineer is a struggle because it is always tempting to add just one more thing. This is why fast iteration and feedback cycles are so important, it counteracts the desire to assume what users want versus knowing what they need.

What about situations when the market is full of similar products or features? It still makes more sense to release in faster and smaller iterations, because the feedback loops allow you to gain insights in finding gaps that can uniquely differentiate your product. In parallel, you can use others mechanisms like mockups and templates to confirm decisions ahead of building the next set of features.

What is something you are building now that could be better handled by an existing service or software platform? What constraints are holding you back from iterating faster?

Mark Birch, Editor & Founder of DEV.BIZ.OPS

I hope you all had a wonderful Lunar New Year celebration and I want to wish you a prosperous and healthy Year of the Ox. It just happens to be my favorite sign as I was born in the year of the ox!

Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!

Thoughts on developers, digital transformation, enterprise agility, community building & software engineering culture. Author 👉

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store