In the recent weeks, I’ve had a lot of talks about the topic “Remote Development Environments” (RDEs). The reason: We are planning to develop a RDE-Product. This means to get thorough feedback and input. What do companies want, what do developers want, what are the must haves, dealbrakers, wow features and nice to haves?
During these conversations, I noticed an interesting contradiction: The perspectives of managers and developers seem to diverge strongly when it comes to the acceptance of RDEs. This article is about analysing this contradiction, the different perspectives and the reasons for it.
ToC
The contradiction: Managers vs. developers
Managers seem to think that RDEs could solve a lot of problems for them, but that their developers would get in the way. Developers, on the other hand, seem to think that RDEs would be great tools for them, but that management wouldn’t understand. How does this happen?
The managers’ perspective
Most of the managers understand and quickly confirm the added value of RDEs.
They know that their developers spend a lot of time unproductively setting up their local development environments, fixing bugs and simply waiting for things to happen e.g. for the local build to be finished.
If I suggest RDEs as a solution, most of them see many attractive benefits of the features offered in RDEs. For example, the protection of source code and test data, the standardisation of the environments and the central administration via one system. However, there are concerns about acceptance among developers.
Why is this?
Managers seem to assume that RDEs are something that developers don’t want. Even if they tell me that it would be an interesting product for them, they seem to be fixated on the assumption that they would have to push through the introduction of RDEs against the resistance of developers.
The developers’ perspective
When I talk to developers, the feedback is usually immediately positive. They confirm that local development environments are tedious. Even developers who like to deal with DevOps topics admit that it would be nicer if they could solve problems more sustainably with their local build. More sustainable than the usual quick fix on one’s own laptop, which is implemented as a quick-hack, just so that they can continue working again.
Many developers are just bursting over with ideas for features that they would like to see in RDEs and that would make their lives easier. First of all, not having to worry about everything working: At the push of a button, a pre-configured development environment in which the software to be developed runs easily, the build is fast and all the tools they need run smoothly.
This coincides with my perspective. I see RDEs primarily as a tool for developers. Something that should save time and make their lives easier. Our RDE tool should also primarily oriented towards the requirements of developers. From my point of view, an RDE has to be something that developers want and like to use.
When I ask developers if they think there is a budget for something like this in their company, most of them say they don’t know: developer experience is not a top priority. They tend to assume that they would not be heard if they asked management about RDEs.
Take the productivity of your IT team to the next level. With Remote Development Environments
In this whitepaper, you'll learn how Remote Development Environments (RDEs) help reduce the burden of maintaining the Local Development Environment and increase the productivity of your IT team.
Download nowHow do these different perspectives come about?
“Why wouldn’t developers like that?”
When I ask this, most managers answer that developers want to have full control and freedom of choice over their development environments. If you force standardised environments on them that they have to use and that they can’t customise down to the last detail, then they probably wouldn’t want that.
On the other hand, there are many developers who say they want a standardised environment. They say they want a thing that they can deploy at the push of a button and that simply works. That they don’t have to worry about. Not a single developer has told me that infinite adaptability is a requirement. But it is important that the RDE does not get in the way. So everything a developer needs to work productively must be possible.
However, developers do not demand root access out of principle or a lust for power, but unfortunately purely out of necessity. Most of them would much rather not need it. So that they don’t have to deal with which packages are available in which version with which access rights, in order to be able to straighten it out if necessary. Most people don’t want to deal with that. Most software developers prefer to develop software and leave the operating to their colleagues in the operating department.
Do managers overestimate developers’ desire for control? Do they underestimate the pragmatism (one could also call it laziness) of developers? Where does this perspective come from the developer who likes to spend hours on how to customise the colour scheme of her IDE, but who goes on the barricades when this possibility is taken away from her? And where does the assumption come from that standardised tools prescribed by management do not correspond to what developers want?
I know developers as pragmatic people. Customising their own development environment is primarily done in the service of productivity: they set up their own environment in such a way that they reach their goal as quickly as possible. I know developers as lazy people (in the service of productivity!) who automate even small things so that they never have to do them again. Sometimes they underestimate the effort of automation, so the ROI for some things may be negative. But working on developer tools, in my experience, is rarely done for the fun of tinkering and mostly for the desire to save time and increase productivity.
I’m a manager and know well the frown when our developers spending too much time on their tooling. Again and again I have to ask how big the problem really is and how expensive the solution is. Developers usually answer this question pragmatically: “Yes, well, it’s not worth it.
This answer often comes with relief. Because: very few developers like to do this; things like extending the local build script or troubleshooting the CI/CD pipeline or having to deal with the fact that nothing has worked locally since the last Docker update. If I decide that they should solve the problem now as quickly as possible and not invest a lot of time in a generic solution, the reaction is usually a mixture of relief at not having to deal with it for a long time now and fear that the problem will come back and they will have to do the same thing again.
So the interests are the same: Managers and developers both want to spend as little time as possible on unproductive troubleshooting and as much time as possible writing code.
Why, then, are the perspectives nevertheless so different? Why do opinions differ so much on how to achieve this common goal?
The reason for the different perspectives
One reason for the different perspectives is certainly that managers and developers simply have different requirements for RDEs or find them attractive for different reasons.
Since managers are usually the people with the budget, it may well be that products are often geared more to their needs than to the needs of the users – in this case developers.
| Managers | Developers |
|---|---|
|
|
There are different goals that are being pursued: Managers are more responsible for risk and security, and therefore more interested in features that increase security and minimise risk.
Developers often experience security features as a “burden that gets in the way”. This is a classic conflict. Here I see it as the task of tool vendors to enable a balance that allows sufficient security at sufficient cost (in developer time).
In the big picture, however, the interests of managers and developers coincide: both want to use the developers’ time as efficiently as possible. They see different features as useful for this goal – which is why the basic willingness to deal with developer tooling is higher among developers than among managers. But still: the goals are the same.
Therefore, both managers and developers are convinced that RDEs are a useful thing. Yet both think that the other group would not see it that way. Why is that?
The crux of the matter
The crux of the matter is quite simple: it is about power. It’s about who makes the decision.
When I sit down at eye level with developers and ask them what they would like to see in an RDE tool, they assume,
- that it is something that is made for them,
- is geared towards them,
- useful to them,
- that they would be the ones to choose that tool and decide to use it.
If that is the case, acceptance is naturally high.
When I talk to managers who have perhaps already introduced tools in the past that they have chosen according to their criteria, they have already made the concrete experience that developers resist. If only because they have something “forced on them” that they did not choose.
Conclusion: The decision-making process for the choice of an RDE tool must be supported by both sides. The product itself must offer valuable features for both sides. Above all, however, it must be geared towards one common goal: it must save developers time, because that is what both the developers themselves and the management are concerned about.
Subscribe to the Cloudomation newsletter
Become a Cloudomation Insider. Always receive new news on “Remote Development Environments” and “DevOps” at the end of the month.
