Updated: Aug 18, 2021
We have been doing Continuous Delivery and DevOps at Wix for several years now and as part of that, I have been training my team at the methodology of DevOps and changing the company's culture. Last week I was trying to explain to some colleagues how we work at Wix and about our dev culture. While doing it I realized that we are doing much more than just DevOps. What we actually do is something I call “developer centric culture” or in short "Dev Centric" culture.
What is Dev Centric culture?
Dev Centric culture is about putting the developer in the center and create a support circle around him to enable the developer to create the product you need and operate it successfully.
Before I'll go into details about Dev Centric culture and why is it good let's look on the problems we have, what we are trying to solve and why it is more than just DevOps.
DevOps is about breaking the walls between developers and operations but after few years of doing DevOps and continuous delivery we realized that DevOps is not enough. The wall between the developers and the operation is just one wall out of many. If you really want to be agile (and we do) we need to break down ALL the walls.
Let's take a look at a traditional development pipeline.
Product that "tells" engineering what they need to do.
Software architect designs the system and "tells" the developer how to build it.
Developers write the code (and tests in case the work in TDD)
QA checks the developer's product and cover it with more test
Operations deploy the artifact to production
So what we have here is a series of walls. A wall between the product and engineering, a wall between engineering and QA and of course a wall between engineering and operation. (Sometimes there is even a wall between architecture team and developers)
When a product manager hands over a spec to a developer, the developers usually don't really read the whole spec, they misinterpret the product manager's intention, they lack the product manager's visions and they are also disconnected from the client's needs.
When you have a team of architects doing all the design and tell developers what to do, you again have a wall because developers might not understand the system's architecture and will not build what the architect intended.
When developers hand over their product to QA you create another wall because now QA need to guess how the system should work and there is also a shift in responsibility where developers don't feel ownership and responsibility to the quality of their product.
Then comes the last phase where Operations get a hold of the product and they are responsible to deploy and monitor a product they know nothing about.
So when something bad happens there is no one who is actually responsible to the product and you start with a blame game. If the product is not what the customer expected then product manager blames the developers that they did not develop the right thing. On the other hand developers blame the product managers for not defining the product clearly. If there is a bug (got forbid) on production then developer blame QA for not finding the bug, and QA blame the developers for writing a buggy software in the first place. If there are stability issues on production then everyone are pointing the figure to operations who do not maintain the product properly; on the other hand operation blame the developers for writing unstable software.
So as you can see there are many walls in the process that we need to break in order to have better quality.
So let's see how we can break these walls, how "Dev Centric" culture helps us with that.
Dev Centric culture means that you put the developer in the middle and create a support circle around him to enable the developer create the product you need and operate it successfully. In a "Dev Centric" culture the developer is responsible through all the product lifecycle, from product definition to maintaining it is production.
Now if you think about a very small startup the developer is the key and is doing everything from talking to customer, define the product design the system, write the code, deploy and maintain it in production. This is also the phase where the startup is the most agile and progress very fast. Now if the startup succeeds and grow, more people join the company and slowly building walls around the different departments that eventually hurt productivity.
Now let's see in more details what walls do we have that we need to break down and how "Dev Centric" culture can help breaking it down and improve the quality and agility of the whole organization.
Wall #1: Product || Engineering The Problem: When getting a requirement to design a new feature or system, the product requirement is defined by the product manager. The product manager sits with the clients, understands their needs and interpret the needs to system requirements. The problem with that is that the product manager does not write the actual code and design the system. The one who is doing that is the developers. If developers get a design document, many times they don't understand the actual customer need, they miss-interpret the product manager thoughts (and between us, they don't usually read the whole product requirement document). This causes a waste of time because the developers might develop something completely wrong that don't meet the customer needs. If the