Risk management of code is an important and often overlooked development function that you need to pay attention to. You may think that this is not a developer’s problem, however developers should not write code that unduly adds to technical debt, hence the need to manage risk.
The primary motivation for risk management is to prevent error or failure. Do not seek to eliminate failure, seek to minimise it, to manage the risk of failure. To do this, we pay attention to the core principles of risk, to quality, reviews, good practise, code as a service, our architecture, and our implementation. Risk management is an essential part of the competent programmer’s toolkit.
Every piece of code, module, or package has an element of risk associated with it. We must evaluate and treat that risk to reduce the likelihood of failure. Managing faults and failures is a separate subject, as is project risk management. By addressing risk exposure at the code development level, you are also addressing project management’s biggest nightmare: cost overrun.
Testing is an effective risk management tool. No piece of code is totally bug free, but we test the code in a domain relevant way so that we know the conditions for success and, by exclusion, the conditions for failure.
At the code level, there is one simple answer to risk management, and that is automation. After the initial risk assessment, automation tools will help to ensure that you can maintain your level of exposure to risk.
The most important factor in risk management is the human factor. Risk management of code depends on the programmers taking a proactive approach to risk in the same way that the testing of code needs to be proactive. Programmers have their fingers on the pulse of risk management, the code, and are key to risk remediation.
This is a classic risk management cycle:
We iterate through it until we manage the risk to a satisfactory level. It’s important to remember that we can only manage risk, we cannot eliminate it.
Let’s see some simple risks we can identify, analyze, evaluate and treat
Setting a standard for requirements can be difficult, the best measure is probably ‘fit for purpose’, some requirements fit onto a card and others need a chapter. If a project has a user guide, a representative of the stakeholders should review the chapter about your module. Requirements should be the foundation on which we build testing. Reviewing requirements is an important part of risk management, in order to achieve a balance between needed functionality and scope creep. Requirements should be clear and succinct.
Managing risk in code is one of the best and most efficient methods of risk management. This is because the quality of code has the biggest impact on risk and is also most easily automated. Risk management in development should be an iteration. Compliance with standards is an excellent starting point. Many will argue for best practice, but good practice is easier, just as effective, and less divisive. Developers need to agree on what makes up good code. Automation of code metrics is useful, but a review of actual code is essential. Pair programming and other Agile practices enable continuous review of code and the consequential reduction of risk. The human factor needs to be optimised so that risk management is part of the development culture.
Testing is proof that code fulfills two main risk management criteria, firstly that it satisfies requirements and secondly that it does so without undefined side effects, commonly known as bugs. Automation of testing is useful, but carries its own risk that automated tests can obscure and obfuscate weaknesses in the code. Testing has to be a team effort with input from all facets of the team.
Data is important for setting the context of risk management. The business domain defines the shape and content of data. Modelling of data is an exercise in risk management that improves our understanding of the business domain. Code must complement the business rules applied to the data. Explore the implications of default values. Data is essential to the exploration of test cases, as is the maintenance of test data.
The software supply chain is an intrinsic part of code architecture. Automation is the best way to control the risk to the software supply chain. Mend has automated tools to manage your open source components and all their dependencies. These tools give developers and security professionals active risk management rather than passive compliance and will keep you updated on the risk exposure of your code.
Change control is a nexus for risk management, an entry point for risk. Change management processes must include change review and approval steps. Again, automation has two aspects, it eases the burden of routine tasks, but may obscure the significance of change.
The first step to good risk management of code is to think about the exposure to risk, the likelihood of occurrence, and the impact. It is impossible to eliminate all risk, but sensible steps can reduce that risk and encourage good governance. Managing human factors is essential to good risk management. Achieved this by encouraging a cultural awareness and understanding of risk among your developers and providing the correct tools to your developers and security professionals.