Today, I’ll teach you how to leverage The Slider Bar Principle to make better software architecture decisions.
The Slider Bar Principle teaches us that most software architecture decisions are fuzzy rather than binary. That is, the possible choices lie along a spectrum.
Understanding this principle is critical, but it’s only the first step. Using it to guide your decision-making process is the only way it can positively impact your team’s outcomes.
Great software engineering teams recognize the primacy of principles. A few decades ago, everyone wanted to visit Toyota. It had become the canonical example of a great manufacturing company. And Toyota invited everyone to visit, even its competitors.
Why?
Because Toyota knew that its competitors would do everything they could to duplicate its practices and tools, rather than understanding the principles of continuous learning and improvement.
Toyota knew that by the time its competitors successfully duplicated its practices and tools, it would have learned and improved.
What is a great software engineering team? It routinely delivers differentiated value to its customers. It can go fast forever. It can respond to changing market conditions and move in the right direction. It can deliver software that runs on day one and keeps running on day two. Teams like this have many common characteristics, but let’s focus on two:
They recognize the primacy of principles. Stephen Covey once said, “there are three constants in life…change, choice, and principles.
This was originally a Twitter thread. I’ve edited it a bit for style and format to make it a bit more friendly as a blog post.
I asked my Twitter following to share with me via DM their biggest frustrations with their day-to-day developer experience. I committed to report back with a summary of everyone’s responses. Well, here’s my report!
Some of their answers weren’t a surprise. But not all of them!