Why Tripod?

When I first published the Tripod project in late 2013, it only offered up the readme.md file that can be seen from the github project homepage. Since then, while it hasn't seen a ton of popularity, the few who have used it have given very positive feedback. A year later, to try and increase the potential for this project to do more good, I've decided to start this wiki as a rough guide to what Tripod is, and how it works.

##Why the name "Tripod"?

How many legs do you need to stand up a table or chair, so that gravity does not pull it down to the ground? It's not a trick question, the answer is at least three, but you can have more. I call this solution "Tripod" because it takes at least three separate projects to form its base structure. You can have more, but you need at least three.

A table with only 2 legs will eventually succumb to the force of gravity and its potential energy will be depleted as it falls to the ground. Why? Because there is nothing to push back against gravity and other forces pushing it downward. Similarly, we as software engineers often have stakeholder forces pushing us to deliver software quickly.

I was talking with a fellow co-worker earlier this week, and I think he put it best by saying that many developers will take the "path of least resistance". Most projects start small, and most of the time stakeholders expect a quick turnaround on their initially small requests. We have rapid application development tools that allow us to quickly get proofs of concept in place with a minimum amount of code. There is no reason to over-engineer at this point because "You Ain't Gonna Need It."

Then if the stakeholders find a use for this proof of concept, it grows. Changes to existing features are requested along with new features. At this point you are actually able to deliver even more quickly because you have already built chunks of code which you can copy and paste to replicate pieces of functionality. You build on more and more, and you don't stop to refactor because if you did, you would begin to miss the kinds of deadlines stakeholders have come to expect from you. You take the path of least resistance.

Eventually the project grows into a product. On this day you become fucked because you finally realize "You Are Gonna Need It." You now you have a shitload of technical debt in the form of legacy code that you have to maintain while figuring out how to scale it up / scale it out / expose an API to integrate with other systems that were never on your radar to begin with. Stakeholders start asking questions like "how long would it take to do this same thing on" iPhone / Android / Windows Desktop / whatever other platforms you were totally ignoring when you started on this small project.

Tripod provides resistance. For each piece of code you write, you need to decide which of the three (or more) projects that piece of code belongs in. It's very easy to write tightly coupled code when you are working with a single project solution where all artifacts reside in the same assembly. Separate them into folders as much as you want, you still cannot write any internal methods or properties which aren't accessible from any other type in the assembly. Just as the 3 legs of a table will push against gravity to support the load it carries, Tripod will push against the temptation to write unlayered, tightly-coupled code. But how?