close search bar

Sorry, not available in this language yet

close language selection
 

Software risks and technical debt: The role of process in determining good software

Understanding how software is developed and the areas impacted by technical debt can help lawyers and investors assess software risks during an M&A.

software risks and technical debt | Synopsys

Insight into how software is developed and what kinds of issues can lurk in a codebase enables businesspeople and lawyers to better understand software risks and how to mitigate them.

Disciplined development is very process-driven. A good, well-executed process, appropriate to the size and stage of the organization, will result in good software. But many organizations don’t have a solid, well-defined process—especially companies that have grown quickly and have a workable process for a smaller team, but have not scaled the process with the team. A suboptimal or inappropriate process can result in problematic software.

Likewise, having a good process but not following it will also result in poor-quality software. There are a lot of reasons that good process isn’t followed; a lack of education and documentation certainly can contribute. But the bigger factor is that most organizations lack the discipline to stick with process when under business pressure. This leads to shortcuts that help in the immediate term but push known and unknown problems into the future.

Examples of technical debt

Technical debt is the result of these shortcuts; it is effectively “borrowing” future capacity to get software out the door quickly today. Some examples of technical debt include minimizing QA time and then just crossing your fingers, and implementing a quick and dirty solution while knowing that it won’t scale in the future. Often, developers take these shortcuts with every intention of going back and fixing them later, but the road to bad software is paved with such intentions.

The insidious thing is that an organization without the discipline to stick with process likely also lacks the ability to track the issues that compose its technical debt. So it can’t quantify the problem—it just feels the weight of it with every development cycle.

Preparing for software due diligence

By understanding how software development can go awry, businesspeople, investors, and their advisors can better assess and understand the implications for software risk.

If you are interested in more detail on this topic, I recommend the “Software Construction and Business Risk: A Crash Course for Investors and Lawyers” webinar.

 
Phil Odence

Posted by

Phil Odence

Phil Odence

Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.


More from Open source and software supply chain risks