Systems, Frameworks, and Shoehorns29 Jan 2013 | by Scott Nesbitt
There seems to be a system for everything these days. For fitness. For productivity. For gambling. For investing. For choosing … well, just about anything you can imagine.
Systems are nice. Or, at least, they can be. But systems can also be a straight jacket. Even if it’s not designed or intended to be that way, a system can be rigid. It can be inflexible.
Whether be accident, design, or habit people mold themselves to the system, instead of molding the system to themselves. They shoehorn their habits, thought patterns, experiences, and (ultimately) themselves into a structure that might not be suited for any of that.
After a while, they either get frustrated and abandon the system, or fall into that endless cycle of trying to hack the system to make it suit them. Neither of which is an optimal, or even acceptable, outcome.
That’s why I prefer working with frameworks. By my definition (and that definition is very loose), a framework is kind of like a system. The biggest difference is that unlike a system — or, at least, the perception of a system — a framework is open. It’s fluid. It’s flexible.
A framework gives you enough scope to mold it to you, and not the other way around. I look at a framework as if it’s a rack with many arms. You hang what you want and what you need on it. Nothing else. If there’s empty space, so be it. It’s your space, to do with what you want, even if you don’t want to do anything with it. Why clutter up something that works for you with bloat that you’ll never use?
But what happens if you’re dealing with an inflexible system? Turn it into a framework. Look closely at the system. Work with it. Analyze it. Then, discard the elements that don’t work for you or fit with your goals and aims. Absorb what’s useful and don’t worry about the rest.
If, at later date, you find yourself running into the limitations of your framework, revisit its parent system. Look at the elements that you discarded from the system and pull the ones that you need into your framework. If those elements don’t exist, or if they don’t quite meet your new requirements, look further afield. Turn to other systems and find those elements there. Or make your own up.
That’s the key difference, to me anyway, between using a system and using a framework. A framework lets you mix and match the elements that suit your needs and your style. A system generally tries make you to shoehorn yourself into its structure.
I go with a framework, or create my own, every time. Why? Structure is fine. But without fluidity, that structure can collapse under its own weight. With a framework, you pick and mix what you need and create something that works for you.Thoughts? Let's start a conversation on Twitter.
Did you enjoy this post or find it useful? Then please consider supporting this blog with a micropayment via PayPal. Thanks!