After my first post about Dev Centric culture I got many questions on the topic which I will try to explain in the next few posts. At first glance Dev Centric sounds like the only one that matters is the developer and everyone else are just simple helpers. This cannot be farther from the truth.
To understand Dev Centric let's take a step back and describe how a company grows but before that we need to understand how a software company ship a product. Like every manufacturing plant a software company also have a pipe line that a product need to go through in order for it to be shipped to the customers.
Here is a standard software pipe line.
Product definition -> Design -> Develop -> Build -> QA -> Deploy
When a company is small you have only a handful of developers which are the pipeline, and do all the work. They design, code, deploy, maintain, do QA and also define the product. However while good developer can do all these tasks it comes with a price, they do not focus on what they are best of, which is writing code.
So in order to make the product better a company hires a product manager, which is probably going to do a better job at designing a product than the developer. Product manager has better skills and specializes in product definition phase of the pipe line. Now while the company is small PM work closely with the developers with a lot of collaboration.
Same goes with QA, operations and architects which each one can probably do a better job than the developer on their own field of experties. While the company is small they all work together. However when a company grows then walls starting to show as every group want to control their aspect of the pipe line, which in turns causes mistrust, and slows down the whole "production line" as you define more structured process and work flows.
Dev Centric culture tries to make the production line as fast as possible. Now if we look at the pipeline the one person who we cannot be without is the developer. The developer IS the production line, he is the one that manufacture the product. However since we also want the best quality product we cannot give up PM, QA and Ops, they are very important part of the manufacturing floor.
So since the developer is the one that ships the product we want to make the process as fast and as efficient as we can without losing quality. In order for the developer to create the best product he needs to understand it. The best way to understand a product is to help define it. This is where Dev Centric comes into the picture. Developers should work together with PM and help define the product. Not buy getting a thousand pages spec but to sit in the same room with the PM and discuss the product, define it while writing the code. This way the code that the developer writes is the right one and there are no misunderstandings between what the PM intent and what the developer understood.
Same goes with QA. Developers should work closely with QA so they understand each other. QA understands the product the same way the developers do. The developers should continuously release code to QA during the development process to shorten the cycles. The best way is to work Test Driven Development (TDD) where developers are also writing the automated tests for their code and QA backs up the developers with more comprehensive end to end tests which also serve as acceptance tests. Another important role for QA is to review the developer's test cases and point out if there are un-tested use cases. So the same goes with Ops and architect like mentioned in my previous post.
Dev centric basically clears the path for the developer to deliver faster and better product by breaking the walls in the manufacturing floor having everyone working in collaboration and focusing on what is important (delivering the best product) by creating trust between people with different agendas and by doing that create a productive environment.