A Summary of “Out of the Tar Pit” by Jacob Beers

In 2006, a white paper by Ben Moseley and Peter Marks called "Out of the Tar Pit" gave developers new hope for tackling the growing complexity of enterprise-level applications. In the paper, the authors identify several ways application complexity gets out of hand, how to correct it, and how to keep things simple as your features grow.

This talk will communicate a streamlined and concise explanation of the content of "Out of the Tar Pit" and provide concrete examples for developers to apply when untangling the complexity of existing applications.

Transcript

1. A Summary of “Out of the Tar Pit” A Complicated Paper About Simplicity
2. Hi, I’m Jacob • Senior Developer at Ortus Solutions • From KCMO • My 3rd ever talk! ◦ At this point I should know better ◦ No need for a compliment sandwich!
3. What is Into The Tar Pit? • Written by Ben Moseley and Peter Marks in 2006 ◦ Sorry, I can’t figure out who they are! • A mostly philosophical exploration of what it would take to make development better • In some ways very predictive of where we are today • Somewhat difficult to form concrete takeaways from The Original Pyramid Scheme - Beatrice the Biologist (beatricebiologist.com)
4. Nintendo Wii Was Released Apple Releases First Intel Mac “Bucket list” is Added to the English Language Pluto Loses its Status as a Planet ? ? ? ? But First - What Was Going on in 2006?
5. Complexity - It’s a Big Problem • Unreliable • Late • Insecure • Slow • Bloated “By some estimates software problems cause the American economy $59 billion annually”
6. Complexity - Different Sources STATE CONTROL CO DE SM ELLS VOLUME
7. Complexity - State “For every single bit of state that we add we double the total number of possible states.” The simplest program (from the outside) is one with no state… it is also the least useful! Since we can’t just get rid of state, what do we do? Classify it! • Essential ◦ visible to users ◦ Named in requirements • Accidental ◦ Implementation specific ◦ not required in ideal
8. Complexity - Control • Essential Logic - User requirements • Essential Complexity - Managing essential state • Accidental Useful Complexity - Caching, transport protocols, security, etc… • Accidental Useless Complexity - The code you write on a Friday that makes you scratch your head on Monday
9. Complexity - Volume & Code Smells • Duplicated code • Dead code • Unnecessary abstraction • Missed abstraction • Poor modularity • Poor documentation https://blog.cleancoder.com/ Robert C. Martin (Uncle Bob) https://refactoring.com/ Martin Fowler YMMV!
10. Functional Relational Programming (NOT functional reactive programming) FRP is a purely theoretical application framework the authors made up but never implemented. • Feeders - convert input into (INSERTS, UPDATES, and DELETES) • Observers - produce output in response to a change of state (TRIGGERS) • Relationships - avoid subjective implementations of you data model (VIEWS) • Looks A LOT like a modern MVC app • Separate presentation and persistence logic • Clearly define input vs derived types • Build relationships without thinking about “accidental” requirements • GraphQL - Feeders = mutations; Observers = queries
11. The Solution is Simplicity Simplicity makes software easy to • reason about - fewer bugs, easier to spot • change - faster feature delivery • transfer to others - faster onboarding/reduce bus factor • test - confidence How do we achieve simplicity? Avoid Separate *Define *Classify *Layer
12. Takeaway - Simplify Requirements The authors make a distinction between informal and formal requirements. • Informal requirements come directly from the client • Formal requirements are what the client agrees to ◦ Created by the developer ◦ Classify input, derived state, and outputs ◦ Ruthlessly (and reasonably) eliminate Additional Resources • https://en.wikipedia.org/wiki/SMART_criteria • https://en.wikipedia.org/wiki/Progressive_enhancement
13. Takeaway - Simplify by Separating • Functionalize • Classifize • Modularize • Microservice-ifize • Outsource-ifize(?) https://github.com/coreutils/coreutils Almost every program in coreutils is non-trivial and yet they are efficiently used by developers and in automated environments around the world. ls is one of the first commands people learn on the CLI and yet it is over 5k lines of C!
14. The Real World - Separate Part 2 Adding tests to an existing system that wasn’t written with them in mind is PAINFUL. How can we make it simpler? If only the app was smaller! Modularizing isn’t just about reusability. It’s also about simplicity! Your Killer App Your Killer App Module
15. Layering - Separate pt 3 Remember this image? I’m going to use it again! The transfer of energy correlates with an increase in complexity. Layering is powerful! “Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem” - David Wheeler Layering is great - but it is easy to forget about and easy to overdo.
16. Takeaway - Be Functional When Possible What if we have to reverse the list?
17. Takeaway - Be Functional When Possible Four changes are required to reverse the list!
18. Takeaway - Be Functional When Possible We only need one change!
19. Conclusion The #1 takeaway? Difficulty is often a sign of complexity. Complexity is most often solved through the right application of: • Define • Classify • Avoid • Separate • Layer - remember the food chain! https://github.com/papers-we-love/papers-we-love Thanks for showing up!