An impromptu introduction to Snuffleupagus-Oriented Programming (SOP): https://t.co/jPkjPRgqQr
— Casey Muratori (@cmuratori) July 21, 2015
Sometimes naming something is the best way to start talking about a topic that lots of people do but don't realise or haven't pulled together as a concept. This is one of those ideas that finally has a good (?) name.
How do you build out a new API? Here we are meaning programming contracts effectively. You can hack away until you have something functional, and then start consuming it. Better yet, build it out as code to do a job and then ship it to someone else to try and use.
Most developers get to a point where they see the value in having contract design up front across team boundaries, layer boundaries, reusable components, HTTP/Soap boundaries etc. An evolved design for these will never be as good as an intentional one. And on the flip side, we have all used clunky library APIs in various languages, BCL or otherwise.
What is Mr Snuffleupagus
The name comes from Sesame Street. Muppets basically. Big Bird and Bert and Ernie, Elmo etc. There was a storyline decades ago where Big Bird kept seeing Mr Snuffleupagus and talking about him, but no one else ever saw him. They concluded it was an imaginary creature for a long time. In the show, it was very ambiguous what the truth was. Eventually, they actually saw the Snuffleupagus too and concluded it wasn't imaginary after all. More here.
Enter SOP
The ideas from this story match an approach to building your API.
First, we are going to imagine that what we want to use exists. Then we are going to write code against the API, crafting our usage case, without implementing anything. Once we are happy that our API is usable, we implement it and make it actually exist, make it real. There may be a few tweaks once the realities and limitations of the implementation are taken into account, but the idea is to try and keep it as usable as the original usage cases as possible, usability intact.
TDD
This is a great candidate approach to work with TDD as well, just with more implementation code along the way to produce passing tests. Like Mr Snuffleupagus, this implementation code is imaginary until you have enough test cases to make it real, and refactor.
Thanks
Go forth and start sharing SOP, Snuffleupagus-Oriented Programming. Imagine, Build Usage, Make it Real. Thanks Casey Muratori for coining the term and making it stick. See more of his programming on HandMade Hero (YouTube), and his company Molly Rocket for games and more.
Top comments (0)