Software Principle 12: There Is No One Size Fits All

Principles are a powerful tool to guide quick and relevant decision making, but every decision should be made on a case-by-case basis using the facts and data to inform the best decision.  

So far, I’ve provided my perspective on principles that have helped me develop my skills as an engineer and apply them to business situations as well. Principles are a powerful tool to guide quick and relevant decision making, but every decision should be made on a case-by-case basis using the facts and data to inform the best decision.  

Occasionally, it will be as Ray Dalio puts it in his Principles book: “Just another one of those” and a principle that exists will apply fully. In other cases, more nuance is required. Tailoring your approach and application of software principles is a must. There is no neatly packaged, one-size fits all solution to development, business, or really any problem.

This series allowed me to share my high level, non-nuanced version of my principles to building software that have helped me deliver systems over the course of my career. These principles are meant to provide simple ways to guide decision making, particularly in circumstances that require a quick response.

However, with these principles, they do not include patterns from other parts of software development like UI/UX, Product Management,Project Management and the many other disciplines that are required to build thoughtful software. These are high level, architectural principles and don’t even include many coding patterns needed for an amazing implementation.

Principles can be built by observing patterns over time; by writing down the problems and how you solve them. In software, this means observing issues that often arise in different systems and projects and writing them down. Eventually, you will notice that many of the problems are caused by similar culprits. This will be the birth of a principle.

The interesting thing about principles is that no two people will observe the same problem: they will come to a completely different decision on how to resolve it and why it was a problem in the first place. This is caused by different experiences, different world views, and different skillsets from an implementation and architecture perspective.

Is one person wrong and one person right? Often times no.    

We should always strive to find the actual root cause of any given situation and ensure our solutions fix the entire problem, not just a subset of the problem. This requires a multi-faceted approach.

Even with software principles, one issue that arises is that they often can’t be used by themselves.

For example, “earn your complexity” by itself will result in a race to the bottom. You should absolutely earn your complexity but consider another one: we must account for change as well.

Even if you don’t see the complexity, it doesn’t mean it doesn’t exist. You’ve earned a certain amount of complexity in any situation and you must figure out where that complexity is and apply the proper principles to deal with it. This comes back to seeking out the root cause of the problem and understanding factors that surround the problem.

My goal for this series was to inspire people to write down their principles and really think about how they solve problems and what their general go-to patterns are as they pertain to their work. In general, being more methodical can never hurt.

Communicating those principles gives teams the ability to have a domain specific language about solving problems, which can be incredibly powerful.

Building thoughtful software is my passion, as is sharing my learning experiences from my career as both a developer and entrepreneur.  Looking forward to writing more in the future!


Build Thoughtful Software
Andrew Wolfe
Written by

Andrew Wolfe

Andrew has an M.S. in Computer Science from Georgia Tech University. But he prides himself over 10 years of experience working in the software industry for well-known companies such as Diebold, Tableau, Explorys, and Onshift. After years in the corporate and startup worlds as well as running his own consulting firm, Andrew realized he had to do more to improve software products and practices. From that, Skiplist was born. Skiplist is the opportunity to focus on thoughtful, quality software and change the software consulting industry.