Coding for Risk/Reducing Code Branches Share Written By Russ McClelland Tags 2023-06-27 I often work with development teams that have complex cycles for coding, pushing, merging, and reviews. Frequently, these have been implemented in the hopes of preventing some issue with potential risk or poor development practices. While this seems to be common, its addressing the symptoms of a larger problem: lack of design.If features are designed before developers begin writing code, patterns and techniques can be used to address risks of bad code impacting a release. It is important to note, that in this context, a "release" does not necessarily mean "production". It can be a deployment to any environment. If you know how the feature will work, starting with the actor, you can begin developing from the bottom up to address risk. This allows you to continuous deliver incrementally and even to develop against the main source trunk - with no risk. Consider…• If you add a table and nothing references it, is there any risk in Production?• If you add a stored proc referencing the table, but no service calls it, is there any risk in Production?• If you add an API calling the Proc referencing the table, but nothing calls it, is there any risk in Production?• If you add UI code to call the API calling the Proc referencing the table, but you hide "the button", is there any risk in Production?• If you hide "the button" behind a feature flag defaulted to "off", is there any risk in Production?If you correctly answered "no" to these questions, congratulations! You're on your way to realizing that most of what developers fear is actually unfounded. You can start thinking about how to simplify your processes, develop faster, and deliver sooner all while reducing risk.