Over the past few months I've discussed in my blogs how to better work with the open-source community and third-party software suppliers. (See: How to Work Better With the Open-Source Community.) Continuing our discussion on the different forms of the software supply chain, this month we look at the best practices for software governance for internal software supply chains.
An internal software supply chain results when multiple teams work together on components of a system and there is a handoff or integration of these components before they can be assembled into a functioning product. Often, internal teams are siloed organizationally, and visibility can be poor across teams. Having teams in different geographies can further complicate things by introducing time zones, complex scheduling, poor communication, and cultural barriers.
One way to combat these issues is to define a framework for common objective standards for software quality and security, and to integrate software and test it regularly to ensure it meets these standards. Here are some of the areas that can be managed:
- Software quality: Modern static analysis solutions provide a cost-effective and automated way to provide a metric for software quality. By setting a policy that defines classes of critical defects and the allowable defect density, different components can be measured objectively against each other and problem areas can be identified early. By increasing the visibility of software quality on a continuous basis, teams are motivated to do their best to keep up with their peers.
- Technical debt: Code that works functionally might still be built in a poor way that makes it hard to maintain. The notion of technical debt captures the idea that a byproduct of developing some code might be a debt that needs to be paid off later in order to add new features in the future. If a project accumulates a lot of technical debt over time, the speed of development will gradually slow down more and more until adding new features is very expensive.
Traditional testing is not sufficient to get a handle on technical debt because it affects the malleability and cost of software in the future, not the features that work today. To get a handle on technical debt there are multiple metrics, including cyclomatic complexity and code comment density, which can help catch code that fails to meet basic best practices.
- Software security: Security risks are ultimately caused by software flaws. By ensuring that poor practices are avoided, many security vulnerabilities can be eliminated during development before they become an issue that a security auditing team must deal with, or worse, cause a security vulnerability in deployment.
There are common threads through all of these areas that form the core of software governance. These are:
- Defining policies based on actionable metrics.
- Testing code to determine compliance with these policies.
- Managing teams to ensure violations are addressed and additional actions are taken to bring teams back into compliance.
This basic process is similar to the high-level governance practices followed by other parts of organizations, such as finance and legal, but they are largely foreign concepts in the world of software development. That will someday change. What do you think?