Feature Request - Assess the risk

Ideally, everyone involved in software should understand that there are risks to every change made. As a software engineer, we strive to assess those risks and communicate them so organizations can make appropriate decisions. This section is a high-level overview on quickly assessing the risk of a change. Unfortunately, there’s no replacement here for experience. If there’s no margin for error, be prepared to wade into the codebase.

Will this require changes across the project?

Generally speaking, the more cross-cutting a change is the riskier it is. If you’re changing a single function, but it’s responsible for connecting to your database, that’s a fairly risky change. This is because if it goes wrong, it’s going to have dramatic effects on the system. When looking at an issue, consider what parts of the system will need to be updated and how they will need to be updated. Then work through what systems those changes will impact and so on. You don’t want to shy away from risky changes, but you should approach them with a good understanding of the implications.

How comfortable are you with the code?

As you work within a codebase, you start to build a mental model of the entire codebase. The more you touch and the deeper you get involved, the more comfortable you become for future changes. That familiarity means you’re less likely to be surprised by what you find. On the other hand, if you haven’t worked with the codebase before, it can only surprise you. This means you’re bound to make a false assumption which is going to wreck any estimate attached to that assumption. This means the change is riskier for the organization.

Another thing to consider is how long ago did you last work in this area of the code. Like any cache, our memory may hold stale data, leading to us thinking we remember something only to find out we’re wrong. Perhaps the best advice here is to validate your key assumptions before major advancements are made based on those assumptions. A key assumption would be any assumption that would cause significant problems if it’s invalid. How do you know if an assumption would cause significant problems? By understanding what that assumption means by either being familiar with it or checking what that assumption actually involves.

Does the code have tests?

A reliable test suite is invaluable when making changes to a codebase that you’re unfamiliar with. It can objectively prove that your new changes will run successfully. If you know that the codebase has tests, there’s less risk of a change causing catastrophic problems or have a long string of follow-up bugs. On the other hand if there are no tests, any change is inherently risky. Perhaps add “write tests” to your project action items.

Is there a maintainer available for advice?

Us mortals can only understand so much code in a short amount of time. Even if we try to review code before making an estimate, we’re likely missing some key context. One thing you can do to reduce the risk is ask the previous person to work on it for advice or to review your thoughts. Their insights can help you identify where you need to exercise caution. That type of information is a great boon to properly estimating effort.

Is there a power user available for advice?

Sometimes the best person to ask a question about how a system works is a user. Ideally, this won’t be a paying customer, but rather a co - worker. You’ll need to do the translation from their understanding into code, but their insights on how things work, run and flow can be extremely valuable to assessing new changes.