The Back Side of the DevOps Trend

Posted on: 2016-07-12

At this moment, if you do not agree that DevOps is the best thing in the world - your are out, well not in the "gang". Indeed, Facebook do it, Google do it, Amazon do it and Microsoft is also in transition to do it. Everybody do it, so it must be the best thing in the world? Well, if you remove the fact that DevOps always existed in small companies, than it is nothing new than simplifying your workforce expertise into a big bucket. The concept of DevOps is that an individual can contribute almost end-to-end of a product. If you want, this is the opposite of what Henry Ford used to be efficient. It is the opposite to divide to conquer. So, instead of having 1 analyst, 1 developer, 1 tester and 1 IT guy; you just use a single person that know everything. This is something you have to do if you run a small company because you do not have enough money to support all those expertise to be spread on different person. With DevOps, the same person setup the server, go talk with customers, do the planning, code the product and test it. The reason behind having huge corporations going in that path is mostly because it increase the deployment time of feature. The justification is true in some extend because you have less overhead of communication and also less waiting for a particular set of skills. Also, you have a team that have better overall picture of the system. So far, everything is "better" on paper. Who can argue against that every one can be easily replaced or that anyone do a better development since he or she knows how to code from a testing perspective or a deployment perspective. Last thing, this also merge the support team with the development team. So, they are no anymore a team that is doing the new stuff and one that is repairing it.

However, here are some problems. If you are "DevOping" only for a part of your organization, than it is not really more efficient. For example, if you have 3 levels of manager that must agree for every decision than you have DevOps for your "coding operation" not for the overall "development operation" of your product. On a small company, you talk directly to the boss and thing can move fast -- sometime the boss is also a developer! It works. However, if you need to include in the loop your lead developer, you manager level 1,2,3,4... than you product manager which must go in meeting with other managers, you loss a lot of benefits like deploying fast new features, having innovative features developed, etc. In fact, from my experience, people are waiting and while they are waiting they are trying to understand the field of knowledge that they do not understand. When they are not waiting, they are doing stuff, but most of the time is on researching about the knowledge that they do not know. At the end, the proportion of time passed into developing the feature itself is not high at all. Also, since your development team is handling all the support than the development that was supposed to be more efficient is cut by the time of understanding every bugs, making the fix, testing again, etc. In a single week, the development time is shrunk rapidly.

DevOps has a bigger caveat if you have a big software : the code. For example, a software that is built by 10 developers or 100 developers or 500 has more different coding standards across the product and also a lot more codes for the same development period of time. This mean that just for development tasks, this require a huge investment of time to understand the current code base. This is not without saying that their is so many technologies implied now that reading the code base force you to know more than just 2-3 languages, it can go very fast above 6-7-8... At that point, we are not even talking about front-end and back-end code. DevOps merges front-end and back-end dev but also, like I said analysis tasks and skills; design tasks, tool, standard, meeting ; coding with different technologies, standards, best practices, debugging and software; testing with unit test frameworks that is different from techno to techno but also from unit, integration, functional, etc; deploying locally, on a server or on the cloud; infrastructure with cluster, load-balancing, network VPN, DNS; etc. So, after a few times, expert in some field become average in every fields.

It is impossible to have a single individual that is an expert in CSS, JavaScript, TypeScript, Angular, ASP, SQL, ORM, Rest Service, security, cloud storage, deployment, unit testing, etc. Indeed, a single individual can be an expert on multiple technologies and systems, but not all of them. This is why the model of Henry Ford was good for development of thing that does not change because every phase was mastered by a single entity. In software, everything change, so a pure segregate model does not apply, but on the other spectrum, the "know it all" model does not either. This is also even more true with the new trend of having new version out so fast. Today, code base is working with version 1 of one framework, in 1 month it will be version 2 out... multiply that by the tremendous amount of frameworks, libraries, technologies required and you are almost changing every weeks something. Keeping track of the good way to do stuff become harder and harder. Of course, you can learn on every task you must do, but still, you will know the basis without being an expert. The cherry at the top is that now, is that every thing is shipped so fast that it contains bugs which if you stumble into one that you are often said that "it is open source, fix it" --indeed.

So, I am all about having a wide range of knowledge. I never been someone that was dividing the front-end development from the back-end development. In my mind, you must know how it works from the request that ask the web page to how to get the data from the database (or other source). I am also all into having developers building unit test and even integration test. In fact, I have projects that I do end-to-end. However, from my professional experiences, if it goes beyond that point and you have a huge code base, the performance of the team is not better with a DevOps approach than having some experts in every part of the process. In fact, it is worth because we are all average and we loss the expertise. Whilst your expert programmers are doing functional tests, or try to see how to deploy on the IIS farm or need to go in meeting with managers to figure out what to do, they are not at full speed at what they are good at. Also, some developer does not have any interest to do analysis, neither to gather requirements, doing tasks management or to work with third party partners -- they want to do what they know the best develop. Same thing for testers or any other expert in the team.

This trend is strong right now, and will be there for few times before migrating to something else. Management likes DevOps because they have a pool of individual that can be easily switched and allow them to have for few days a full team of developer and tomorrow a full team of testers as well as one team in one product today which can be moved into a different division later. I am not against that movement, but contrary to a lot of people, I simply do not think that this is the way to go in long term. Keeping developer having expertise without having them exhausted with all those different tasks and technologies to keep up is going to be challenging.

To conclude, I am curious to see why this mentality does not goes in the management's zone. Because, DevOps could also be applied: we should only have 1 layer of ManOps: "Management Operations". All the benefits would be also there. Faster decisions, less hierarchies to reach the person who can do something tangible, no middle man or distortion of information, faster delivering features or innovative ideas to be incorporate inside the product...