Types of Risk

1 link


Updated October 11, 2022

Unfortunately, because a lot of risk management comes down to experience, you won’t learn everything there is to know about it in this section. What you will learn, however, are the different types of risks so that you are aware of what to look out for in your day-to-day roles.

  • Technical Risks

    • Poor code quality

    • Poor technical decisions that prevent you from adapting to changing requirements in the future

    • Lack of documentation and knowledge sharing

    • Poor technology choices

    • Poor code performance

  • Scheduling Risks

    • Poor project estimation

    • Requirements that are not finalized and keep changing

    • Lack of visibility into the work that is in progress and what has been completed

    • Project scope creep

  • Operational Risks

    • Poor communication

    • Lack of proper training

    • Lack of effective processes or procedures

    • No separation of concerns, or checks and balances

    • Data breach due to poor security practices

  • External Risks

    • Sudden market changes

    • Increasing competition

    • Government regulations

    • Changes to consumer behaviors

    • Weather and natural disasters (yes, really)

This is by no means a comprehensive list of every risk involved in software engineering. There are many additional categories and subcategories of things that can go wrong while keeping software systems running. Luckily, you’re not the only one responsible for managing these risks. Risk management is a team effort, but that doesn’t mean you’re off the hook when it comes to doing your part.

Contributors to Technical Risk

Let’s look into some of the major contributors to technical risk that you should look out for in your day-to-day role.

Overengineering vs. Underengineering

Effective engineering is about shipping software quickly while preserving your ability to make additional changes quickly in the future. The goal is to move fast without putting yourself in a situation you’ll later regret. In essence, we need to build software that meets the current requirements for our customers but leaves enough flexibility to easily extend the code to handle additional requirements in the future.

You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.
If you found this post worthwhile, please share!