The Six-Legged Triangle of Doom

I want to introduce you to something I’m calling the “Six-Legged Triangle of Doom”, aka “How To Develop: Choose Your Own Adventure Style” or the “Development Kite of Misery”. If you’re completely confused right now that’s OK, I promise you’ll be less confused in a little bit. But for now, lets look at this chart-thing:

Behold, the Chart of Doom.

This is the Six-Legged Triangle of Doom. Yes, its a diamond.

I’m going to make a bold statement and say that every piece of software creates a triangle overlaid on this chart. Lets look at some examples:

Here’s the chart for MySQL:

As you can see, for the most part, MySQL is a really good product that is relatively easy to deploy. They’ve done a good job of setting sane defaults and making it simple to get a development DB up and running in no time. However, its definitely not very scalable without bringing in dependencies like Galera or using vertical scaling, which is where it’s banked some technical debt.

Here’s the one for Kubernetes:

Kubernetes is a very solid, very good codebase that is close to infinitely scalable, but Sweet Baby Jesus is it difficult to actually deploy in production. Its complex and complicated, making getting a production-ized Kubernetes cluster up and running in a state where you can onboard applications a daunting task at the very least.

And lastly, just for fun, here’s Nagios:

If you’re still using Nagios then you’re doing it wrong.

Not only is Nagios difficult to deploy and maintain, but the code is bad, and they’ve incurred so much technical debt that frankly the entire thing should be canned.

There’s a point to all of this, actually, and not just to poke fun at Nagios. It can sometimes be hard to articulate the struggles that we as developers face when designing and writing a new application. Often times product owners want things fast, perfect, and easy, but those of us who live in reality know that’s pretty much impossible. Having something like this to reference can be a valuable tool for managing expectations: it can be scalable and good code, but it might be hard to deploy, etc. Additionally, framing tech debt as an antithesis of scalability can help non-tech managers and product owners understand why refactoring to eliminate tech debt is necessary, even if the result is sometimes completely invisible to the product owner.

—

How do your favorite apps overlay on the Triangle of Doom? Let me know in the comments, I’d love to see your assessments!