This post is the second and final piece in this series. To read the first, click here.
We have seen a lot of movement in the direction of Continuous Integration (CI) and Continuous Development (CD) [CI/CD] in our industry. It is still making its way into all aspects of software but, in my opinion, will be one of the baby steps required to address these gaping holes of quality in our industry. Here is a very brief description of CI/CD for those that may be unclear on the concept. As the code is written and put into a Source Code Management (SCM) system [or code repository], an orchestration tool like Cloudbees Jenkins copies that version of the code and compiles/builds the software. The orchestration tool then runs automated unit and integration tests against the build and reports the results. The feedback at each interval lets the teams know how they are doing in the progress of bug fixes and new features for the next release. This cycle of continuous feedback allows the software and testing teams to be much more efficient in delivery of their software. With CI/CD, as changes to the frameworks come out, the teams can inject the new framework and test to see how well or poorly the new framework works with their current codebase.
Since we are talking about testing, the biggest difference between non-IT and IT, that I see, is that in IT, there are some assumptions in testing that exist that don’t exist in non-IT. When a plumber installs pipe that has been tested by the manufacturer, the plumbing company still tests the system that is installed to make sure it all works as a unit. They start out testing the joints and welds but when the system is complete they test the entire system. In IT, we seem to enjoy the blame game. “That is not my code so I shouldn’t have to test it.” I ask, “why not?” If the whole system, the framework and the code we wrote, is completed, why not test the system as a whole at the end? It is possible that the manufacturer of the pipe missed a quality test or had a bad batch of metal or had a general issue with the manufacturing of the pipe. When the plumber tests the system, usually they have tested their welds and joints as they install them. They could make an assumption that the system should all work but the good ones don’t. This is the part of understanding that seems to be missing from IT. If the system does not work, the customer does not care whose fault it is when it breaks. They want the system to just work. We need to have a standard with the flexibility that all software must work at the final stage regardless of individual testing.
Last but not least, we need to have a standard of documentation. When dealing with a plumber installing a new hot water heater, the documentation of how the installation is done is standardized. The next plumber can see the specs on the hot water heater and knows what should have been done. With IT, it is not uncommon for entire systems to be installed with “tribal knowledge”. Some verbal knowledge transfer that is discussed but not required to be memorized. Common phrases like “it is documented in the config file.” or “any admin should just know that” or “that is how we always do it” are uttered as systems and software is installed. The next person coming in has to dissect the systems and softwares to get an understanding but usually does not bother to document it for the next person. We need to, as an industry, to come up with standards in writing documentation as well as standards to help others use and replicate our systems and softwares. We are an industry that seems to enjoy reinventing the wheel and wondering why we don’t progress as fast as we would like.
Want to join the conversation? Feel free to email me with ideas / concerns with standards in the industry at email@example.com