Talking to directors of engineering and CTOs, I have heard many of them say that they absolutely expect every developer to know how to deploy their software. When I ask why, the answer is that knowing how the software is deployed makes developers better developers.
In this blog post, I want to take a look at this belief. Does knowledge about deployment make developers better at their job? If yes, how so? And what is the best way to teach developers about deployment?
I also recorded a video on this topic: https://www.youtube.com/watch?v=ZaEFX5DS25g
Why do most developers know about deployment?
A majority of developers run the software that they work on locally, as part of their development environment. This is why many developers know a lot about the deployment of their software: Because they do it regularly in order to validate their code changes in local deployments.
However the sad truth is that deployments are often very complicated, and developers spend a lot of time and nerves getting local deployments to work.
Fortunately, there is an alternative. Cloud Development Environments (CDEs) make it possible for each developer to have private playgrounds where they can validate their code changes before they commit them to a shared repository. CDEs are functionally equivalent to a local deployment, with the difference that they are fully automated and provided to developers remotely. With CDEs, developers can build, test and deploy their code in their own private environment in the CDE with fast feedback loops and with no danger of interfering with other developer’s work – and without having to know anything about deployment.
This is why it makes sense now to ask if developers need to know about the deployment of the software they work on. Previously, there was no other option. Now that there is an alternative, I argue that we need to rethink the scope of what developers have to do and know about.
What are the upsides of knowing about deployment?
Knowing how to deploy their software can enable developers to make better decisions when writing code, particularly around:
- Configuration of their software
- Core architecture of their software
1. Configuration of their software
When a developer has to deploy the software they work on themselves, they will intimately know how this software has to be configured. Since developers are also the ones who decide how configuration can be specified for their software, they are much more likely to consider the user experience of configuration when developing configurable features. This is probably the main benefit of forcing developers to deploy their software. Choices about how a software can be configured are something a (backend) developer has to do reasonably frequently.
2. Core architecture of their software
The core architecture of a software hugely influences how simple or complex its deployment is. Deployment therefore has to be considered when deciding on the core architecture of a software. However, since architecture decisions are typically made once early in the development of a software, it is the architects or CTOs who take these core architecture decisions who have to know how they plan to deploy their software. For the majority of software developers, this is irrelevant.
Summary of upsides
So we are left with configuration. It is undoubtedly true that a developer that has had to deploy software that is hard to configure will be more motivated to make their software easily configurable. But relying on this as the mechanism to ensure well-designed configuration for a software is a bad idea. Like any aspect of the software that has a large impact on user experience (in this case the experience of the deployment and operations team of a software), it is something that should be designed by a knowledgeable specialist, who provides guidance on how configuration should be done for a software that other developers then have to follow. This is how feature design works, after all. Otherwise, it will still be each developer deciding on their own what they consider “good and simple configuration”, which will be different for each developer, which most likely again leads to a poor configuration experience overall.
What are the downsides of knowing about deployment?
There are two main downsides of requiring developers to know how to deploy their software:
- Time sink: It eats up time and headspace.
- The myth of the full-stack developer: Few people have the skill and inclination to be good at both coding and deployment.
1. Time sink
Knowing about deployment, and having to deploy their software on their own laptops regularly as part of their daily work, are two different things. Unfortunately, the latter is the sad reality for many developers, and it is justified with the “need to know about deployment”. I have already described that knowledge about the deployment of a software has only marginal benefits for developers. In addition to this, the second misconception is that local deployments as part of a developers work are a good way to teach developers the things that they should know about deployment. It is not.
If you want your developers to know about the pains of deployment, it may be a good idea to ask them to manually deploy the software they work on as part of their onboarding, or as a regular exercise every once in a while. If you really think that knowing about deployment is valuable for your developers, then this is a good way to teach them: If the deployment is painful, they will remember it very well.
If developers do local deployments daily, they will get used to many of the pains of it and lose awareness. That removes even the marginal benefit of developer’s knowledge about deployment: They might not even try to make it better anymore.
But the worst part is that it eats up developers time and headspace on a daily basis. It is a cost factor that many companies are not much aware of, because time spent troubleshooting local deployments is typically not tracked separately. Instead, it is padded on top of each task that a developer works on. But the time spent on local deployment can reach as much as 25% of a developer’s time (in extreme cases), and typically is somewhere between 5-10% of time of a developer when it works fairly well.
That is a LOT of time!
2. The myth of the full-stack developer
The scope of what a developer is supposed to know is seemingly endless. Even though many specific job titles exist that describe people whose primary focus is deployment and operation of software (operations, devops, site reliability engineer (SRE), …), developers are often assumed to be able to fulfill those functions in addition to their primary function. Often, testing, user experience, architecture, backend and frontend development are also mingled in, leading to the all-encompassing job description of full-stack developer.
There are people who know a lot about many aspects of software development, who can reasonably claim to be full-stack developers and do a decent job in any of the mentioned areas. But for most developers, working as full-stack developers will result in products like this:
The truth is that most people, including developers, hugely benefit from specialisation. Having one area to focus on where one can build up knowledge allows one to reach higher levels of productivity and expertise much faster than when developers are asked to learn about everything at once.
This is especially true for complex software. State-of-the-art business software nowadays often has a lot of components and highly complex deployment logic. As long as deployment can be expressed with a simple “npm run build”, any developer will be able to handle that. But that is hardly ever the case anymore. Many developers spend 10% or more of their time just managing local deployments. The majority of this time, they spend on troubleshooting. But in order to troubleshoot local deployments, developers do not only have to spend time – they also have to know a lot about tools like Docker or minikube or other tools specific to the deployment of their software.
Bottom line: Expecting a very broad skillset from developers will exclude the majority of developers from fulfilling such a role successfully. Even those few full-stack developers that do exist, each one will have specialties and areas where they are less skilled. Finding people who are good in one area is much simpler and will lead to much better outcomes for everyone.
Conclusion
Deployment is an important aspect of a software. It is probably a good idea for most developers to know at least a little bit about the deployment of their software, much in the same way as it is a good idea for each developer to know how to use the software they work on so that they can make better decisions about user experience.
However, much in the same way, developers are not generally required to (or trusted with) making decisions about user experience on their own, even if they have intimate knowledge of the software. It is simply not their speciality. There are user experience designers for a reason, because it is a complex area of expertise that requires knowledge and inclination that doesn’t necessarily overlap with that of a developer whose job it is to write code.
It is exactly the same with deployment. Deployment experts exist for a reason – because it is a complex area of expertise that not every developer should be expected to master, on top of their development expertise. Developers should be required to follow best practices or company-internal guidelines when making decisions that influence deployment. But they should not have to spend hours and hours each day struggling with local deployment.
My conclusion: CTOs and directors of engineering expect their developers to handle deployment because:
- It has always been this way and they may not yet realise that it is not necessary anymore.
- Knowing about deployment serves as a proxy for the general skill and knowledge of a developer. (I could also put it more bluntly: It propagates the unhelpful stereotype of the all-knowing full-stack developer as the ideal developer.)
Neither reason stands up to scrutiny.
Bottom line: It’s expensive and has few benefits
To summarise: Few developers have the inclination, experience and skillset to fulfil the stereotype of the full-stack developer that knows how to code and deploy their software. Knowing about the deployment of a software has only marginal benefits at best, but requires a lot of time and energy to learn and manage.
Consequently, forcing developers to learn about Docker, minikube, network configurations and a whole lot of other things and tools that they need only for local deployment is a huge waste. Developers generally don’t even like doing this. It is a drag on both productivity and happiness.
This is good news! It means that there is a huge amount of time and headspace that developers could stop investing in local deployment. There is a big opportunity to make developers a lot happier and more productive.
And fortunately, it is easily possible to spare developers the pains of local deployments. CDEs are tools specifically designed to do this. They allow developers to focus on writing great code, without having to worry about deployment.
More about CDEs:
Top comments (0)