Adam Smith, a pioneer of political economy has predicted the essence of industrialism, that is the division of labour. He argued that, businesses will be much more profitable by splitting tasks formerly accomplished by one person in a single day, into many discrete tasks carried out by multiple people over their whole careers. Which is the reason why you would hear titles such as Senior Channel Executive or Chocolate Beer Specialist. This was the fast track industrialism, you could put 100 people in a room of 1000 square meter, mark a line for everyone, define what they are going to do, and build your product line and produce the same product thousand times a day.

Assuming you have hired all the required skill sets, how would you create a production line for software development? Software development is a complex process because you can not draw the production line because software engineers are knowledge workers and the knowledge worker’s primary task is non-routine problem-solving. Therefore, creating teams and building barriers between them creates a gap of knowledge, the knowledge, that is in the gap and not shared properly, is required to solve certain kind of problems that arise while developing software.

For instance, if a team of software developers builds a software, another team tests this software and another team takes care of delivering the software. The gap between each team creates problems that causes software to be either delivered too late or with problems. As an example, big companies with hundred of engineers, change management is a bureaucratic pain, which takes up to 3 to 4 months to update something small that probably takes less than 15 seconds. The reason behind this delay is, people who develop software are not the same ones who put it into the production. As a result, deployment of the new applications is risky, because the operation team does not like to take the risk, as it is their job to keep to system stable. If something goes wrong, developers argue that either it works on their machine (my favourite sentence!) or it works in the development environment. There are many other problems as such, the source of many problems are creating squads out of Engineers which are afraid of each other and keep fighting about whose fault is the latest mistake. The question is: How can it be solved?

Recently, there has been a new method of software delivery and maintenance, a method called DevOps. DevOps is a combination of the words development and operation, which simply states that in software development and operation teams should be closely integrated. The ultimate goal is to set a close collaborative working relationship between everyone involved in the software delivery in order to get the software into the production faster, less error prone, and more reliable.

DevOps are not the revolution of the developers who take the control of everything. It is the reconciliation by doing the obvious one, building the software together. Now imagine the environment which people, who develop software, are responsible for delivering the software. This does not mean installing a web server on a local machine and running the software on it. It means knowing how to bring the software that you have developed into the production. The tasks are quite challenging such as  setting up the network, the security, maintaining the databases, monitoring, release management, etc. And, yes Adam Smith was right, the more specialised the workforces are, the richer the economies will get. In DevOps scenario, you need operation people right next to developers to build software together, release it together, maintain it together. When developers become aware of the ‘how software runs’ on actual system, they can develop better software, when operations know the reasoning behind the decision that developers took, operation team can build better environments that are needed for the software.

Upshot!

There are of course problems with this method, as in any method. Nevertheless, benefits outweigh the problems, such as continues software delivery, faster delivery of features, improved communication, stable environment. I do work in a similar environment and I, for one, believe it to be an effective way of developing and delivering software products. So if this is the case, can you still argue that DevOps are good or bad? Well, this is not a single size fits all solution, there are people and environmental factors involved in the situation. If both are right, meaning if the work environment has diverse and good skill set and which nurtures their developers by trusting them to do failures, this method can be applied. If not, better try something else.