Skip to content

Cloud Development Environment Adoption (aka Waiting for Godot)

I have been thinking about cloud development environments for quite some time. And for me it always feels like the “year of the cloud development env ” just like the year of Linux on the Desktop or the year of VR. Over this time, I have never really been a believer and was quite willing to tell people so.

Other than some specific use cases, for the next 5 to 7 years, Cloud Development Environments (CDEs) will see poor adoption in the application developer community. And on a trip to London, I explored my thinking with James Governor. He engaged with me in exactly the way I was hoping – sound arguments and a little bit of smack talk and he even wrote a blog post about it.

I have been working at large software companies that sell to enterprise companies for over 12 years now and for at least the last 8 years there has been some internal hysteria that we weren’t doing enough to win the cloud development space. I have seen PMs say we need to stop working on IDE plugins and go all in on cloud otherwise “we will get left behind”. You hear other PMs, VPs, and sales people say “management at company X would love a cloud development environment – solves so many problems for them”. And yet, it is still barely a thing after all this time and hand wringing.

I do recognize that the technology for cloud development environments has gotten better. I also recognize there are some environments where CDEs make a lot of sense. But I am still bearish on the idea that the needle will move in any appreciable way towards cloud development environments.

Technology is only a minor part of the problem. The CDEs now offer near instantaneous start times for the environments, some requirements already present, and really quick to gather other requirements. But quickness of spin up, while important, is quite low down the Pousty Hierarchy of Application Developers Needs (™).

I tried GitHub Codespaces and fell into frustration within the first 10 minutes. There is no doubt we are at a stage where a “cloud infrastructure” can be spun up on demand in a reasonable time. And, this could be me, the doc, or the user experience, but within ten minutes I wanted to get out of my seat and go for a walk. I will save that discussion for a future blog post.

Developer’s desire to have their environment on their local computer primarily does not have to do with the power of their development environment. Faster and lighter computers are not what keeps developers away from cloud development environments.

Just to be clear when I talk about development, I am focused on inner-loop, rapid iterations throughout the day. There is a vital part, usually after a git commit, which goes through some CI/CD system to run the tests and check if all is good. That makes a lot of sense to put in the cloud since most developers who code daily are fine treating that part as a black box. They can commit to git and get back to their work and just wait for “the system” to tell them if their code passed or not.

What’s the problem

The real issue here is the ability to self-serve and control. Application developers have been bitten too many times by tools that have said “you just drag and drop and away you go”. That stuff works until it doesn’t or it needs to be customized — there be dragons.

Developers have spent hours, days, months waiting for IT to give them a database, allocate a VM, or approve a package for development. Those on tightly controlled laptops have been out of commission for days while they wait for some IT deity to deem that they now have time to fix their machine. These locked machine victims have sat in workshops watching other people do the exercises because they couldn’t install stuff on their laptop – even into user space.

The real issue with cloud development environments

Both the “it works out of the box” and the “we’ll manage that for you” prevent a much higher need in the Pousty Hierarchy of App Developer Needs (™) – the ability to Get Shit Done.

Application developers want to work when they want to work and how they want to work. As been stated many times throughout the tech world – developers just wanna’ get shit done. Anything that helps them do that is good and anything that prevents that is bad. Waiting around for an admin to add the right dependencies to your environment, having a working laptop but for some reason the server is down, something is horked in my development environment and having few ways to troubleshoot it – these are all bad.

Another problem, but less than the one above, is moving files in and out of your Cloud Dev Environment (CDE). When I am doing inner loop development, any non-trivial procedure to move files around is bad. For example, I am designing a web page and I am playing around with the size of an image on the page. My CDE will most likely not have image editing software and I will have to edit on my machine and then either:

  1. Check the file into a local git repo, push to a remote repo, and then pull the image into my CDE.
  2. Save the file locally, upload to the CDE file system, and then, if I am lucky it will be exactly where I want it or I then have to move the new image around to the right location.

Either scenario leads to frustration, frustration leads to anger, anger leads to hate, hate leads to suffering.

Cloud Based Development environments take control and troubleshooting self-sufficiency away from the application developer. It can add friction to what should be a simple process. These control and friction issues happen at a much higher frequency than setting up a local development environment or creating a new service.

There is a short gain in the beginning of projects for potential frustration and blockage throughout the life of development.


If you don’t know, the acronym it stands for, Not In My Backyard. The idea is someone is all for a project for social good or a necessary burden as long as it doesn’t affect them.

In my experience, talking to app devs, both inside and outside my work, or when I run informal polls on Twitter, most app developers agree.

Cloud development environments seem interesting, other people should definitely use them, but don’t make me use one.

It’s fine for other folk, it might even help them, but leave me alone.

Usually if app developers hear about interesting technology they want to try it. They need that cool new cutting edge bona fides on their LinkedIn profile. The fact that I have yet to hear application developers asking for this and the fact that they actually are reluctant to use it does not bode well for the uptake and spread of CDEs.

Then Why Do We Keep Hearing About Them

Well just like VR, CDEs are an interesting technology. It makes for good copy and interesting salacious predictions about the future – just right for tech media and analysts. They are cloud based so that must mean they are part of better technology for better living. “The future looks bright with CDEs”

The vision of it sounds great to IT higher ups. “Wow, if I adopt this, onboarding for a project will be so frictionless – how do I get my devs on it”. They seem to weigh, for good reason, the cost of project onboarding higher than devs in their hierarchy of needs.

Higher ups are usually pitched or exposed to “new and exciting” tech by sales people. CDEs are definitely shiny and show well to execs – which also makes sales people happy. Therefore there is a high reinforcement of signal that does not account for the desire of the users to adopt CDEs.

Finally they really do make sense for some use cases. A few of examples are:

  1. High security environments.
  2. Online teaching environments
  3. Teaching workshop to people where you have low bandwidth or attendees who may not control their computers.

I am super psyched for using CDEs when I teach workshops. In that scenario, easy provisioning and startup times are critical since I have less than a day, usually less than 4 hours, to teach everything. There is no time to spare figuring out why one attendee can’t get the library to load up on their machine.

CDEs are really good for short duration projects or projects where there is a very high security requirement.

Wrap up

Based on the discussion above, you can see how I might not be bullish on the near term future of CDEs. The bet between James myself was that, at the end of 7 years, CDEs will have less than 20% adoption among enterprises (there is no telling what those crazy independent hipster developers will do). Sometimes I feel like I made the odds a bit too easy for James, but go big or go home right?

See ya in 7 years from October 2022.