DevOps are not enough: Part 3 – Quality as Code

Quality as Code

(Read Part 2, "Risk as Code")

Quality of code is a topic known almost since the early days of programming (around 1970). First, it was about bug-free code, then – documented code, then code compliance with code standards and best practices. Nowadays, requirements to code quality are increased and ask not only for clearance, simplicity, accuracy, security and elegance, but also for

·??????performance and de-coupling,

·??????reliability and robustness,

·??????flexibility and adaptability,

·??????testability,

·??????maintainability and manageability.

The enumerated qualities are usually realised or have to be realised by an additional code, which we call Quality as Code. Thus, code quality and Quality as Code are different matters. If we strip the operating code from additional code (Quality as Code), the original code can lose certain quality.

The mentioned above list is not full and should be extended, but the article explains only these qualities.

Performance and de-coupling – it is not a secret that the same task can be coded is a few different ways. Since modern programming languages are running on top of low-level languages and constructs created at different times, the performance of code depends on all – lower-level code performance, higher-level code performance and code combination design. So, the code performance is a balance between simplicity and efficiency. Distributed computing adds complexity as a cost for other qualities unavailable in the monolith design. Distribution not only distancing/de-coupling code fragments from each other, but also demands additional code (Quality as Code) that enables interactions between the code fragments. Therefore, the performance of Quality as Code should also be counted in overall code performance. For example, at the Application Level, the highest performance belongs to a direct synchronous interaction between code fragments. At the same time, if this interaction is conducted over the network (like REST), it has minimal reliability and robustness and an alternative asynchronous messaging with lower performance may be more preferable?(both REST and messaging constitute Quality as Code).

Reliability and robustness – code reliability indicates the ability of the code to run without failure, i.e. it may be an average time between failures or probability of code failures or over a specific period of time. Code robustness is the ability of code to continue execution (even partially)?in unexpected failure conditions. Thus, reliability requires recording all code failures, e.g. logging and/or reporting (Quality as Code), and robustness needs an additional code (Quality as Code) that would be able to continue running if the core code fails to perform its task. In some industries, a “code/task, failure” is not an option despite any methods of development, deployment and execution and the Quality as Code is a must-have.

Flexibility and Adaptability – in the current context, code flexibility is about code changes in response to external factors; code adaptability is about an adaption of a code fragment to the changed execution context, which does not necessarily result in the code change. For instance, AMLD v.5 requires that each financial transaction contained information pointing to the beneficiary of the transaction. So, the code composing the transaction’s message, e.g. for the Open Banking API, should be changed quickly and easily to include the beneficiary’s identity, plus, an additional code should provide the identity. This is a new requirement to be addressed via flexibility. In contrast, a service that calculates the price of a mutual fund should be adaptable to the execution context. As an example, the calculating code should engage an additional code (Quality as Code), which has to recognise where the service is used – whether it works in the UK or in the USA – because these countries use different local financial regulations and count the price using different formulas.

Testability – not every code can be easily testable. SW testing includes special input and outcome data as well as pre-conditions and post-conditions. The former pair requires additional code that controls/reports the input and outcome data while the latter pair is more complex in implementation and can ask for additional manipulations with configurations of the run-time environment. Certain types of testing are mandatory for particular code and, while testing is already a part of DevOps practices, its automation created additional challenges and complexity, and requires extra time. This leads to the temptation of reducing testing as much as possible, especially for the regression and integration tests. All testing activities obviously demand extra code (Quality as Code) and time. It is more likely than not that regression tests are skipped in full and integration tests are substituted by connectivity tests. Since the quality of outcomes is not the major attribute of DevOps work (or less important than the time of delivery), DevOps have created a ‘fantasy’ that all consumers will collaborate with them and help them to refine the code. This idea has been taken in isolation from the context – while internal consumers might provide feedback to the DevOps Team, the external consumers will likely turn away from the ‘raw’ product toward a competitor’s one.

Maintainability and Manageability - maintainability is a degree of easiness in the software maintenance. It relates to the size, consistency, structure/modularity, and complexity of the codebase. Any deviation from a monolith structure toward modularity requires additional code (Quality as Code) for connectivity between modules either at the higher or lower levels of code. Code management is?the process of handling changes to code and, at least, a process of tracking modifications and managing changes to code. While code manageability comprises many operational activities outside of the code itself, effective manageability assumes behavior code monitoring embedded into the original code. Such monitoring also constitutes the Quality as Code.

?Observed Security as Code, Risk as Code and Quality as Code practices jointly represent minimal requirements for DevOps work in the modern development process. These practices are equally or, in many cases, more important than just ‘bold’ time to market because competitive advantages, gained by an organisation due to the delivery pace, can be lost thanks to insecurity, unacceptable risks and low quality of code. Even worse, not only advantage may vanish, but a company can lose some customers who become unhappy with such products/code.

Automation of Security as Code, Risk as Code and Quality as Code is possible, if not today then in the observable future, based on AI/ML. Until this becomes available in the market, companies have to either build this automation in-house or perform Security, Risk and Quality controls manually / routinely while DevOps ought to accept interruptions and slowdowns in their delivery process since uncontrolled code is “not done” yet.