|
I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future. In addition, paid subscribers form their own community of folks investing in improving software design—theirs, their colleagues, & their profession.
This article was first published in 2022. It has become newly relevant because remote development environments turn out to be key enabling infrastructure for remote genies.
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.)
Welcome to new sponsor CodeRabbit. As I continue to write more code with AI, I long for a "what all did the genie do?" tool.
CodeRabbit offers this visibility, providing code reviews right in the IDE (for individual coding insights) and on PRs (to ensure consistency and quality across your org). CodeRabbit fits into existing toolchains and git-based workflows, can be personalized for individuals and teams, and can be used in conjunction with some of our favorite AI agents (including Claude Code, Augment Code, Cline, etc.).
Sign up today and see how CodeRabbit can cut bugs and review time in half (while also letting you keep tabs on your augmented coding projects).
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?
You’re currently a free subscriber to Software Design: Tidy First?. Buying me more time to think & write means more thoughts & ideas for you.
|