Our developers are set in their grumpy old ways and unlikely to want any change

Cloud development environments (CDEs) aim to revolutionize the way developers work. Workloads shift to the cloud, environments and tools become standardised, all with the aim to reduce the time developers spend waiting and troubleshooting.

Sounds like a no-brainer. But it can be hard to introduce CDEs in engineering teams. Switching to a CDE can require developers to fundamentally change how they work. And not all of them want that. In fact, in a recent interview with a development lead, this is what we heard:

“Our developers are set in their grumpy old ways and unlikely to want any change.”

It doesn’t matter how good a tool is if the people who should use it don’t want to change their behavior.

Change is hard

While not all organisations are this much in thrall to their own developers, it is quite common particularly at older organisations. In such cases, there tends to be a cohort of developers that

know the codebase,
that have special knowledge or skills that are hard to replace,
who wield outsized power over tool choices and work processes.

In more positive terms, many companies value developer experience and want to provide their engineers with tools and processes that they like to use. It is not so much that developers are “set in their grumpy old ways”, but that developers in general are a very discerning user group. They have high expectations regarding their tools, they are hard to convince, but often, when they are a fan of a tool, they stick to it loyally.

Learnings

At Cloudomation, we took two learnings from this:

Frictionless migration: There has to be an easy and fast migration path from current tools and processes to new ones that we propose. Ideally, the developer will have to change their habits as little as possible, with our tool enabling noticeable improvements in harmony with existing tools and processes. Related to CDEs, this means that using the CDE should be indistinguishable from developing locally, ideally with the developer being able to switch seamlessly between using the CDE and their local toolstack.
Bottom-up: Developing and selling developer tools will only work with a bottom-up approach. We need to build a tool that developers want to use, and we need to develop it to their needs and tastes.

How we do this

Frictionless migration was a requirement for Cloudomation DevStack from the start. We want to fit DevStack into developer’s processes as seamlessly as possible. This means that:

Developers can use whatever IDE or editor they choose. To support this, DevStack allows caching of source code locally in a shared folder with the CDE. This is unique to DevStack and enables truly free choice of local editor or IDE.
- Note: It is not a must. Developers can also choose not to cache source code locally and e.g. use an ssh-capable IDE – if they want to.
Developers by default get full access to the CDE. This means that they open a terminal, ssh to the CDE, and can work with the shells and tools available there via the terminal in exactly the same way they would work with their local terminal.
Developers can select folders on the CDE which are synced to their local machine. If developers need to work with files other than code, e.g. if they need to check changes that their software does to files, they can do that locally without having to copy files around. Again, to the developer, this means they can work like they are used to working when they deploy their software locally.
Developers can choose how to deploy their software, with deployment directly to the CDE-VM as default. We make no assumptions, allowing the developer to define how they want their deployment to look like.
Developers can use existing configurations to customise their CDEs. For example, user-specific dotfiles can be deployed to the CDE.

Generally, our approach is to assume as little as possible and leave as much room for customisation as possible. With sensible defaults, the developer can get to work quickly, but if they want, they can customize their CDEs to their heart’s content.

The bottom-up approach means that we want to get input from users as early and frequently as possible. Right now, we are conducting a lot of interviews with engineers and engineering leads to learn about their requirements.

We use Cloudomation DevStack internally every day and let our developers prioritize what to focus on. If you want to give us your two cents: try out the public demo of DevStack and give us feedback. And we have launched our closed beta of DevStack – let us know if you’re interested to join!