Tensegrity

It’s been a while since I posted anything. Sometimes life intrudes on posting, but I’m back to posting again. Today’s question is, can you push something with a rope? Sure, you can do it if the rope is short enough that it effectively can’t bend, but what about a longer rope? You can’t. But you can make it look like you’re pushing with a rope. You do it with tensegrity. Tensigrity is not new. The first examples were shown in the 1920s, and Buckminster Fuller (of geodesic dome fame) coined the term in the early 1960s. It’s the idea that by properly pre-loading the elements of a structure, some in tension, some in compression, you can build a stable structure. From an architectural standpoint it lets you right-size different components based on the load each component will actually be carrying. It also lets you build apparently impossible figures where chains push things up.

That’s really cool, and I need to build one of them, but what in the wide, wide world of sports has that got to do with software?

Simply this. When building complex systems, you have multiple competing forces (requirements) that you need to handle. You can do it in multiple ways. The easiest (from a design standpoint) is to make sure that each individual component can carry the maximum load of the entire system. Now building each component that way might not be so easy, or might be so expensive as to be impractical.

That’s where tensegrity comes into play. The forces are in balance. Putting one piece into compression puts other pieces into tension. That pulls things back to equilibrium. It’s a feedback system. It’s systems thinking. This applies to software as much as it applies to architecture.

It’s not that you can maintain everything the same in the face of increasing stress (load), but that you spread the load so that the system doesn’t fail catastrophically. The load on one system influences a different system, which in turn impacts the load on the first system. Consider a simple retry system. If something fails, instead of just retrying, add an increasing backoff time. That reduces the load on the downstream by temporally spreading the load. Good for the downstream system, but it does increase the load on the sender since now it needs to keep track of retries.

It’s by no means a magic solution to all your problems. As you can see in the GIF above, as long as the system is in balanced tensegrity, it stands. Add too much load in the standard direction and something will break. Add too much load in an unexpected direction and the system can’t compensate. Instead, it fails in a new and exciting way.

All the parts are fine, but the system isn’t holding. Like all other solutions, the answer to the question of whether it’s the right solution for a given situation or not is “It Depends”. And like every other solution, it’s one to keep in your toolbox for when the time is right.

Plus, it’s an excuse to show a LEGO build video.