DevOps's, are we doing it right?
Long ago, there was a software development model (SDLC) where a system used to be spec'ed and designed as a phase, then came the development and everything else.
Obviously, this model had few problem such as flexibility in accommodating change and time it took to take a functioning system to the end user. At the heart of it all, the real challenge was that it was too late by the time one knew if "the product is being built" because the users (or user representatives) get involved into validating the product at the very end of the development cycle whereas the contrary is what would be ideal to 'build the product right' (by right we mean as desired). Who else but the users (or user representatives) would know what's desired hence its imperative that the users understand what is being built and also take active role to validate/verity/confirm that what's is being built is what is desired. Not after the build phase but while the build is in progress.
Understanding anything in abstract is quite tricky and making such an abstract a basis for a group of people's work elevates the complexity by a great proportion
Understanding anything in abstract is quite tricky and making such an abstract a basis for a group of people's work elevates the complexity by a great proportion. This is exactly what happens in IT project/product development. A set of people come together to create an abstraction aka requirement document/story with acceptance criteria. Names for the people involved and the artifact they produce change per model adopted but largely,the actions and the outcomes remain the same.
People with different backgrounds, level of competencies (aka design, development & test engineers) consume this abstracts and develop and test the product/project, entirely based on their knowledge and ability (or lack thereof) to understand the abstract (by either reading or listening). When this vicious circle of interpretations happen over a period of time in a fairly large group of people trying to build a complex product (which is what happens most often than not), the teams end up with "this is not what I wanted" to "this is not what I start to build" to "this is not what I meant in my specifications". What lies at the center of this confusion is the ability/inability to understand abstracts i.e. someone else's thoughts. This should remind us the famous picture on software development process.
Looking into this scenario, the obvious solution is that the process of building any product/project should be centered on having a partnership and collaboration between the Users/User Representatives (aka Operations) and development teams, i.e. DevOps. DevOps means that the technology teams collaborate with the operations (user group) team on a more fluid basis and the Operations team values the engineering team's time and are prepared to spend time more frequently than they have been. This is both accepting the accountability on the part of Operations group and being open minded & flexible on the part of engineering group. For all those who have interacted with these teams and worked in the Information Technology world know this is more easy said than done.
DevOps is merely a practice and not a development model in itself. An idea, that needs to be implemented regardless of the development model adopted.
While the organizations attempt to address "are we building the product right" problem via DevOps, end up burning most of the bandwidth in building tools that help automate the software development & deployment process, namely Continuous Development and Continuous Integration and fail to create a framework such that the operations team get involved with the product development more organically throughout the journey, i.e. abstract to product. Of course having automation is helpful and one should address every opportunity to accelerate mundane, routine tasks such as build and deployment.
One of the most important reason, the practices such Six Sigma (that has had a huge impact in Manufacturing industry) have been marginally successful in the world of Information Technology is because by nature Information Technology engineering and more specifically testing is a craft best done by a human brain as this craft involves understanding abstracts and creating logical implementation on the go. To say the least, this critical thinking and decision making is something that's very difficult to automate
Under the DevOpos realm, while the testing organizations spend huge amount of time ($$) around Shifting Left, Automating first, Automating everything, testing a product/system at every layer well before the integration, one should recognize the value of Coverage (how much is being testing), effectiveness of testing (whats tested is tested well) and focus on creating a framework to get others groups (Operations, development et cetera) involved in the process by not writing test scripts for them or by sharing pass reports but via active role. Similarly, the development teams while spending time on Robot Coding and Auto Code Generation, one should focus on unit testing, testability (creating testable builds) and more importantly collaborating with the Operations group and testers, not seeking pass/sign off reports but to collaborate as the progress is being made.
