Cloud Development Environments Tame Complexity By Reducing State

When I joined Gusto 3 and a half years ago I got to program production Ruby for the first time. I was excited to get started. Alex, a senior developer, walked me through the steps required to get tests & an IDE running on my laptop. All was well for a few days.

Then I updated the repository & the tests wouldn’t run. “Oh, yeah,” Alex said, “You have to delete this file & re-run that script. No problem.” I did. No problem.

Come the next Monday, though, it was, “Hmmm, I haven’t seen this before.” Type type type. “Let me ask somebody.” Type type type. “There, all fixed.”

Every few days, my development environment got borked. Often it was a quick fix. Sometimes not. But always time taken from one of the most productive programmers (Alex, not me.)

Structural Problem

Developers spend hours a week just being able to program on laptops. Laptops have advantages as a programming location: control, latency, flexibility. However, we just don’t seem to be able to keep them working without leaving the floor covered in yak hair. We’re programmers. Can’t we just solve this problem?

No. As I was getting acquainted with GitPod the other day, it struck me that there is no direct way around the problem of a stable, predictable development environment on a personal machine.

Variability, Interconnection, State, Irreversibility

I learned the following model from Professor Enrico Zaninotto, at the time the Dean of Economics at the University of Trento. Large, complicated system aren’t controllable when they combine 4 properties:

• Variability — the environment around the system changes out of control & visibility of the system.
• Interconnection — the elements in the environment affect each other.
• State — the system can be in one of many states at any given time.
• Irreversibility — changes to the system, once made, cannot easily be unmade.

When all 4 properties are present, there is no way of predicting how the system will behave. Change the system, there is no way of predicting how the overall behavior will change. You can’t understand the system well enough to fix this problem.

His first example was mass production gaining control by reducing the number of states. All Model T Fords were black not because Henry Ford liked black so much, but because “paint or no paint” is easier to manage than “how much of each color of paint to do we have/need?”.

(Professor Zaninotto was trying to understand the effectiveness of Extreme Programming. Software development has all 4 properties. XP, in this model, works by introducing reversibility to software development decisions.)

Applied to Development Environments

How does this model apply to development environments?

• Variability — Yes. Today’s style of development takes advantage of a long & complicated supply chain. All the systems we rely on change independently.
• Interconnection — Yes. The parts of our system rely on each other.
• State — Oh my yes. The current state of a development environment is enormous. What’s been downloaded, initialized, running, messed up?
• Irreversibility — Surprisingly, yes. “Oh, upgrading this messed up that? Just reinstall the previous version.” Yeah, right.

How does this help with my Monday morning laptop blues? We still want to take advantage of variability. We aren’t Forth programmers writing all of our own stack down to silicon. We can’t avoid interconnection.

That leaves us with state and irreversibility. Pre-built development environments of the sort offered by GitPod give everyone using the same environment the exact same state. If today’s pre-build doesn’t work, we can easily load yesterday’s & get back to a known-good environment.

And Then…

I’m excited to see how this plays out. The first advantage for programmers is the time they save. I’ve seen different numbers for the current cost of keeping a development environment working, but it’s certainly tens of percent.

More important, I suspect, will be all the programs that folks will try writing because they are no longer afraid of wasting another 4 hours before giving up. One of those programs that wouldn’t have been started will turn out to be exceedingly valuable.

Interesting problems remain. How does remote development retain the latency of local development? How do you share a remote environment? How do you satisfy the needs of beginner, intermediate, & expert programmers at the same time?