A Culture Called DevOps


Culture is perhaps one of the most misconstrued word in the realm of any organization’s performance or growth as it is the catalyst around which the entire business operates as well as proliferates.

Appreciating the Culture of an Organization

Culture of an organization enunciates the values as well as the work culture and ethics of its employees and explicitly demarcates the manner in which the employees understand and approach each other as well as the work ethics of the company.

How Can we work Smart to Achieve success within Organizations?

To understand this, let us try and answer a few relevant questions about the present day set up of the organizations:

  • What is the companies culture at present?
  • How intricately is this culture in line with the business goals or the KRAs of the company?
  • What would be the problems that could arise in the event of any misalignment

Now, to get the answers to the above mentioned questions, we first need to know the 4 Basic C’s that would define the organizational metrics for any organization:

  •  Collaboration
  •  Control
  •  Cultivation
  •  Competence

Having understood the 4 C’s let us try to comprehend the culture of the software.. 

  • developing companies who have separate teams that manage and build a single
  • software unit and each of them come with a definite goal and purpose.
  • This process commences after the requirements are fulfilled by the organization.

Developers generally tend to adopt the coding guidelines demarcated by their organizations and programming tools like compilers, debuggers, interpreters and the like are applied to optimize the code apart from various niche programming languages like C, C++, PHP, Java, Pascal and others are used to write the code. These programming languages assist in dividing the packages into smaller folders and then develop them into individual smaller codes.

Let us try to comprehend each of the stages in brief:

Stage 1– these smaller individual codes are then conjoined to form a large unit and in the process of doing this, a project level testing called the integration testing is conducted.

Stage 2– once successfully integrated, the codes are then deployed on to a dummy system which comes with a similar configuration as the client system or the system where the project has to be finally deployed.

Stage 3– the project is uploaded on to the client server only after testing all of the features of the dummy system in its totality.

Let us try and understand the glitches that could occur in this process:

Stage 1– the client is in a perpetual search to keep upgrading the process continuously. Just when the initial iteration is done, the client would come up with a few modifications and when the developers start to incorporate these changes, they begin to have an impact on the integration as well which further leads to broken builds.

Stage 2– most developers and the testers would be unaware of the new changes that are getting made and they start working on the changes once they receive the code from the developers, they start implementing them while simultaneously the back end team are continuing to make the changes. As the back end team does not get enough time to apply the new changes, they end up developing unproductive codes and in the process face other database as well as network problems which further delays in the delivery process.

Stage 3– although the build might seem ready to go to production, the results might be completely unexpected and could result in bugs being generated. Now for every bug that gets generated, there has to be a slew of questions that need an analysis-why has the bug occurred, where has it occurred, what are the changes needed to overcome the bugs, will there be changes that will be done on the other codes to make them attuned with the previous ones and many more. Finally, a bug report needs to be generated.

The failure is due to the system errors in the database; developer’s inefficiency in the testing of the code and the tester’s ignorance in the number of test cases. With clients always keeping stringent deadlines, the employees involved would only concentrate in delivering to the deadlines at the cost of compromising on the quality which indirectly speaks about the culture being adopted by the company. One reason for this failure could be a huge dependency on the manual process or a lack of interest or better still a failure to access skills all of which cumulatively add on to the increasing work load.

It is about time that we got our act right by automating our systems to make them recover more rather than make them rollback.

Before we try to appreciate the process changes we need to try and answer a few basic questions:

  •  Where does the company’s present culture fail?
  •  Where does it want to see the changes?
  •  Has the organization perceived the areas that need the        changes?
  •  Has the company asked for and studied the feedback and the buy-ins from all the stake holders?
  •  Has the company reevaluated the process discipline, data as well as the measuring metrics?

It is only when we get adequate and proper answers to these questions can we ponder about revolutionizing our systems. This can happen only when we get processes to a stage of continuous integration and constant deployment. This process of continuous integration and deployment makes it even more agile and it is in generating this agility from where DevOps culture emanates out of.

DevOps is the practice of both the operations as well as development engineers participating in the complete life cycle right from the design through the development process to the product support of the organization. Since transition for any organization would be rather complicated, it would auger  well for companies to renovate rather than rebuild the entire process. Now, there are two ways to get this process of rebuilding done:

  •  The top down approach
  •  The bottom to top approach

In the top down approach, the possibility of presenting ourselves before the higher management and ask for changes across the hierarchy would only succeed if the management is convinced with the changes getting made. But there is every possibility of the management’s negative response as the systems already being in place and it now being difficult to change them.

In the event of the first approach being met with a negative response, we are left with a bottom up approach which would call upon a volunteer who would initiate the change in the DevOps model within smaller groups or teams. It would always auger well for the company to put together a newer set of tools in place rather than overhauling the entire organizational structure. For it is definitely not the tools but the people applying them who are inefficient and incapable thereby complicating the process.

With an enriched vision and process, we can then approach the management giving them a clearer picture of the changes sought and the results that would ensue because of these changes and how the company would deliver quality before the deadlines and by doing so, proliferate the organization’s businesses per se.