Staging And Classifying

Our tour is complete.

We've collected on this journey around the Risk Landscape a (hopefully) good, representative sample of Risks and where to find them. But if we are good collectors, then before we're done we should Stage our collection on some solid [Mounting Boards], and do some work in classifying what we've seen.

tbd collecting image

Some Observations

Your Feature Risk is Someone Else's Dependency Risk

In the Feature Risk section, we looked at the problems of supplying a dependency to someone else: you've got to satisfy a demand [Market Risk], and ensure a close fit with requirements [Conceptual Integrity Risk]. The section on Production Risk went further, looking at specific aspects of being the supplier of an IT service as a dependency.

However, over the rest of the Dependency Risk sections, we looked at this from the point of view of being a client to someone else: you want to find trustworthy, reliable dependencies that don't give up when you least want them to.

So Feature Risk is Dependency Risk: they’re two sides of the same coin. In a dependency, you’re a client, whereas feature risk, you’re the supplier.

Coordination Risk

• similar to _threading/deadlocking issues

One thing that should be apparent is that there are similarities in the risks between all the kinds of

Production risk == security risk??

Boehm.. OWASP..

How much do compilers do for you?

1. Classifying Risks

• Dependencies and Features are the same

  • Dependency risks are all 2-sided. (Counterparty risk)

• Communication is a Dependency

• Fit Risk / Communication Risk - buckets

  • Fit risk example from work: choosing the right format.
  • Why standards can never be perfect.
  • Mention Kanban = the control is the physical object

• Expected Requirement Coverage - diagrams 1 & 2.

• Dependencies and Coordination

• Need to do this again, now.

• In The Bin

  • CapsLock: complexity, not using tools.
  • Configuration Tool (Complexity, feature fit, bugs in hibernate, difficulty mapping domain model)
  • Wide Learning (Funding, but also complexity), did we know what we were building? Agency risk
  • AreAye - needless complexity XMLBox
  • Agora: Notes / Typing. (Complexity Risk) Archipelago
  • PDC: website redesign. funding. i.e. schedule risk
  • Hawk: complexity risk in the software. but actually, they made it work. offshoring.
  • Dark: market/feature fit?
  • J10: marketing / market fit / Complexity in spades. algorithmic complexity
  • DSL: complexity (code generation). complexity = layers. team dynamics.
  • REF: complexity. agency risk. failure of goals. m&t.
  • REF Testing: complexity risk. communication risk?
  • HSC: Trader Comments: feature fit.
  • HSC: Takeover of Symph: Complexity (of change)

2. What's Gone Before

• An attempt to categorize all the ways in which software projects go wrong.

• Boehm.

3. What's To Come

• risk based debugging.
• risk based coding.

4. On to Part 3.

• I'm a better coder for knowing this.
• We're all naturalists now.