In philosophy, a razor is a principle or rule of thumb that allows one to eliminate (“shave off”) unlikely explanations for a phenomenon, or avoid unnecessary actions.
Even if you haven’t heard of Occam’s Razor you most certainly have heard of and followed the concept. Occam’s Razor formally is stated as:
“Entities must not be multiplied beyond necessity”
This is also been paraphrased to be, “The simplest explanation is usually the best one”.
Regardless of which formal definition you use, the concept is the same. Keep things simple and your life will be easier. So, how does this work when building software products? I like to use this example:
Let’s suppose you are developing a web application to track expenses for users. The application will need to allow users to add expenses, categorize them, and view summaries. You have two options for implementing this feature:
- Option 1: Use a complex relational database with multiple tables for users, categories, expenses, and relationships between them. Implement a feature-rich front end with advanced filtering, sorting, and visualization options.
- Option 2: Use a simple JSON file for each user to store expenses, with a basic categorization system. Implement a minimalistic front-end that allows users to add expenses, categorize them, and view summaries.
If you step back and apply Occam’s Razor, you would choose Option 2 as it is the simpler solution. This choice has several benefits. For example:
- Faster development time: With fewer components, you can develop the application more quickly.
- Easier maintenance: A simpler codebase is easier to understand, debug, and modify.
- Lower resource usage: While this might not apply in the case of the simple example I have stated, it certainly is true that a less complex system generally consumes fewer resources, such as memory and processing power.
By following Occam’s Razor, you’ve created a functional expense-tracking application without unnecessary complexity and frankly, without a lot of time. This principle helps guide you towards efficient, effective solutions that are easier to maintain and understand.
Obviously, there are instances where, even in the basic example that I’ve stated where you’ll want to choose option 1 and build the database, but the concept here is that you should stop and ask yourself, based on the information I have today is this the simplest option?
I can’t emphasize enough the “Easier Maintenance” option enough. I have worked on many systems where the complexity made the entire system impossible to update. In these cases, large portions of the system had to be scrapped and rewritten, therefore costing much more time and effort than if a simpler solution had been chosen.
Having built software applications for decades, I can pretty quickly give advice and help you sniff out where you might apply Occam’s Razor to your product development. If this would be of use to you and your team, please feel free to reach out and schedule a free assessment. I look forward to speaking with you!