Why the local development environment should be replaced

Developers work in development environments. This is where they write code, test and debug. A local development environment includes an editor (IDE), a browser, a terminal, a database, the end product, i.e. the company’s software to be developed, and many other tools. The development environment therefore has a significant influence on how productive and satisfied* developers are.

In practice, however, there is a problem: the local operation of the software to be developed is costly and the management of dependencies is tedious and maintenance-intensive. A lot of time is spent solving problems within the development environment rather than writing code for new features. In addition, each developer has to deal with individual problems. This quickly has a negative impact on productivity. There are attempts at solutions (containers, CI/CD pipeline, standardisation), but these are only partially effective.

In this post we describe,

why these problems not only affect the development team, but quickly spread to other areas and the whole company,
what alternatives there are and why the local development environment should finally be replaced.

Local development environment: The problem levels

In order to become aware of the challenges that local development environments bring with them, they are broken down into four levels:

The individual level (affecting the individual developer),
the team level (affecting the whole team),
the company level (concerns the company) and the environmental level (concerns the outside world of the company).

Let’s go through the individual levels.

The individual level

Again and again, developers talk about the following challenges:

Setting up the development environment: The initial set-up of the laptop takes a long time (sometimes even several weeks) because different components and services have to be installed. Often, the documentation is not up to scratch and several employees have to be consulted for questions.
Context change: When working on a different project or switching back to an old version, the required packages have to be installed manually, the database has to be reconfigured and other tools have to be set up again.
Updates & dependencies: Components cause errors – due to an update or due to outdated dependencies. This robs time.
Hardware: The laptop can no longer handle certain tasks because the computing power or RAM is insufficient.
Security: A laptop with company information and source code is worth its weight in gold to attackers. When travelling, there is always the risk of loss/theft.

The team level

New challenges arise when there are multiple development teams in companies:

Use of different tools: Different hardware and operating systems (in different versions) are used. Workarounds are therefore needed for some tools.
Works on my machine: Due to the different configurations, everything works for developer 1, but not for all the others – classic “works on my machine” problems occur.
Cooperation with external developers: Cooperation is difficult due to the individual problems – onboarding also takes a long time and is very time-consuming.
Documentation: The wiki page, which should contain the details for setting up the development environment and for everyday work, is not updated or is updated only irregularly.
Resources: Developers turn to other people to solve individual problems with the local development environment. This means that at least 2 people are involved in solving problems with a development environment and not in the actual work.

The enterprise level

The previously mentioned problems lead to further challenges. This time at the enterprise level.

Productivity: Constant problems with the development environment and the tedious context switching reduces productivity. New features and bug fixes are slow to find their way to the customer. The management puts pressure on them.
Culture / motivation: Developers are increasingly frustrated with their work. This is also reflected sooner or later in publicly visible company evaluations.
HR: The HR department sees a bottleneck in the onboarding of developers. It simply takes too long. In addition, the department has to struggle even more with the satisfaction of the developers.
Leak: If a laptop is stolen and the source code is published, all systems are in danger, the reputation is damaged.

The environmental level

Challenges also arise outside the company:

Customers: Wait a long time for updates and bug fixes. Lose trust in the company and in the worst case look for an alternative.
Others: Fewer applicants, loss of trust.

This list shows: A seemingly small challenge that only affects the development team leads to a huge problem that needs to be thought about across departmental boundaries.

The question is – Why is the local development environment on one’s own laptop still the tool of choice?

Is there no solution in sight?

There are practical reasons for this: Because local development environments can be quickly adapted to other circumstances and offer a high degree of flexibility. In our experience, however, there is another reason: the situation is accepted because these problems have always existed. The frustration tolerance is now simply very high – “everyone has these problems, that’s just the way it is“. Another reason is that these problems are not yet being heard loudly enough by the management. That means: business as usual.

But there are already tools that developers can use.

The alternatives

Virtual machines, Docker and remote development environments are tools to counter the problems mentioned above.

At the moment, this problem is being tackled as follows:

With standardisation (guidelines),
containerisation and with fully automated CI/CD pipelines.

Standardisation via guidelines helps to contain the problems, but is also difficult to enforce. Developers have to use tools and an operating system specified by the company. This often leads to frustration.

Containerisation is another approach that can solve some problems. But here, too, there are challenges and new problems. Read more in our blog post: Problems with the local development environment: Is containerisation the solution?

Automated CI/CD pipelines are often used in practice to avoid having to run the software to be developed locally. However, this alienates the pipeline from its intended purpose. The pipeline should be different from local build tools and be used separately.

A more detailed description of the approaches can be found in the blog post: Why we decided to develop Remote Development Environments (RDEs)

Another alternative that has been floating around in the software development haze for some time, and really took off in 2022: Remote Development Environments (RDEs) / Cloud Development Environments (CDEs). Numerous companies are currently switching to RDEs.

And it’s worth it: it has been observed that onboarding is shortening, build times are improving and troubleshooting is decreasing. Why? Because RDEs run on servers, performance is easily scalable. Any device can be used for daily work.

In addition, the work process improves: switching from one version to another is straightforward. The RDE in which the project is running is simply changed. There, everything is already configured and ready to go.

The protection of the source code is also improved: RDEs can be air-gapped so that the source code and test data do not end up on the developer’s laptop.

It should be noted, however, that the term “RDE” means something different depending on the provider. You can find an introduction to the topic and how the providers differ in this article “What are Remote Development Environments“.

RDEs – production-like dev envs are the future

Developers still have to deal with problems that affect the local development environment on a daily basis. This has to change. Because the seemingly small challenge of “local development environment” brings with it a whole rattail of bigger problems.

We are convinced that RDEs are the future. Cloudomation DevStack – our RDE product – puts an end to all the drama surrounding the local development environment. Set configuration parameters for development environments that your developers then use to create custom, self-service RDEs. Production-like development environments are immediately available. Has this problem been an issue in your company for a long time? Then Cloudomation DevStack is an option you should consider as a solution.

* https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance&sa=D&source=docs&ust=1691659380434514&usg=AOvVaw3Lkb3whTD6Ba2KoyDzFC0Q