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 in which 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.

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
CODE
SMELLS
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!