Skip to main content

Implementation Risk

Risk that the functionality you are providing doesn't correctly implement the perceived solution you are trying to build for your clients.

Part Of

Reduced By Practices

  • Analysis: Ensures that requirements and specifications are clearly understood before development begins.
  • Approvals: Ensures that work meets the required standards and specifications before progressing.
  • Automated Testing: Ensures that individual components work correctly and detects regressions early in the development cycle.
  • Change Management: Avoid bugs from creeping into the system.
  • Configuration Management: Establishes and maintains consistency in the software product's performance and attributes.
  • Debugging: Identifies and fixes defects in the software.
  • Demo: Demonstrations often highlight issues in implementations
  • Dependency Adoption: Ensures consistency and reliability by adhering to proven standards and libraries.
  • Design: Guides the development process, ensuring that the system meets requirements and design specifications.
  • Integration Testing: Validates that the implementation meets requirements and detects regressions early in the integration phase.
  • Issue Management: Tracks and manages defects and issues, ensuring they are resolved.
  • Measurement: Identifies areas of improvement in the implementation process.
  • Pair Programming: More eyeballs means fewer bugs and a better implementation
  • Prototyping: Helps identify potential issues before full-scale development.
  • Refactoring: Enhances code quality and maintainability.
  • Regression Testing: Detects and prevents regressions in the software.
  • Review: Ensures quality and correctness of work products.
  • User Acceptance Testing: Validates that the implementation meets the specified requirements.
  • Version Control: Maintains a history of changes, allowing rollback to previous versions if needed.

Attendant To Practices

  • Coding: Changes in code can introduce new bugs and regressions.
  • Refactoring: Done carelessly, refactoring can introduce new issues into the codebase

Implementation Risk exists in the gap between what you are trying to build and what you actually build. That is, the difference between your software in theory and in practice. It includes things that don't work as expected, that is to say, bugs and missing features. A good way of looking at this might be to consider it the sum of all the development items you have on your to-do list.

Worked Example​

Reducing Implementation Risk Via Automated Testing

In the above diagram, we can see Implementation Risks being addressed by Automated Testing - building out a series of examples and running them to make sure the software behaves as expected. The downsides of this may include the extra complexity in the project and the impact to the schedule of building the tests.

As you can see from the table at the top, many of the practices we adopt in software development have been designed for the purpose of tackling Implementation Risks, but incur their own overheads in terms of effort and time.

Example Threats​

1. Incorrect Assumptions about Inputs​

Threat: it's easy to assume that the most common form of input represents the entire class, only for unusual or obscure or unusual input cases to reveal themselves as implementation issues.

2. Leaky Abstractions​

Threat: In a similar way, abstractions that make sense in the design phase can often fail to usefully model real-world concerns.

3. Not Working As Advertised​

Threat: A lot of programming languages and libraries purport to giving you a certain piece of functionality which you come to rely on or expect in your own code. However it later transpires that they don't completely meet your expectations. Your work has been built on top of faulty assumptions.

4. Unfamiliar Domain​

Threat: If you or your team are using new tools, working in a new domain or making use of unfamiliar algorithms or libraries you should expect elevated levels of implementation risk while you build your Internal Model of that domain.

5. "Hard" Domains​

Threat: Implementation risks are more prevalent in certain areas of computing, such as concurrency, memory management, security, algorithms with complex time/space tradeoffs and so on. See Complexity Risk and Security Risk.

6. Regressions​

Threat: Existing features in your software get broken when you add new ones. Customers don't have the features they expect.

Anecdote Corner

Implementation Risks lead to bugs and disappointed clients, but often the results are more serious. The original wireless (WiFi) network protocol, IEEE 802.11 from 1997 was supposed to offer security via WEP - Wired Equivalent Privacy. However, there were severe design flaws in the algorithm and in the early 2000's it was proven to be completely insecure to the point that you could fairly trivially recover a WEP pass-key just by snooping the encrypted network.

Having security experts review the standard would have helped, however there is also legal context around this that the US had export restrictions around cryptography at the time which would have hampered strong wireless security anyway.