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

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.