When in a competitive business environment under the strains of the triple constraint (time, resources (cost) and scope), you have to minimize the risk and minimize the TCO (total cost of ownership) while maximizing the ROI (return on investment). But how do you determine the risk?

I commonly use a "bets" model for helping developers work with and understand risk. I ask: "What bets are you making to use this technology and what bets does the company make when using this technology?" It's common that developers will not be able to list the large bets. That's OK. If you're not familiar and accustomed to thinking in these terms then you can't be expected to do it well.

Let's try an example exercise using a fictional product called WonderWidgets. What are some of the bets that you're making if you use WonderWidgets in your project? (This list is by no means exhaustive. If you think of a bet that I'm missing, let me know.)

• Does WonderWidgets meet the needs (requirements) for your project? If your needs are not well known then this bet may become very large. Is there sufficient documentation (traditional docs, blog entries, forums, etc) for you to know if WonderWidgets meets your needs? All of this needs to be added up and a bet made.

  You can certainly divide this one big bet up into its constitutients if you feel more comfortable.

• Is there anyone on the project (or at the company) that's familiar with WonderWidgets? If not, big bet. This ropes in the "hit by a bus principle", the time to learn, the total learning curve, etc.

• Following along the same lines as the previous point: the company would be making a big bet by using a technology at the core of its application that is likely to be understood by only a single developer (i.e. the "bit by a bus principle").

• Are there working examples available (anywhere) that outline most of what you're trying to do with WonderWidgets? If not, big bet. This touches on some of the same points as the previous bets: how do you know if WonderWidgets can do what you need it to do? Having examples will help mitigate learning time and determining applicability.

  Notice that I didn't just say "are there examples of code using WonderWidgets". There are two common siutations that you have to be aware of:

  • Are there examples that run under the current version of WonderWidgets?
  • Are there examples that address your particular project's needs?

• Do you understand the impact that WonderWidgets will make on the rest of the software / architecture / team? If not, you're making a bet. This component has a lot of factors that come into play such as understanding how invasive WonderWidgets will be on the rest of the software.

• Take a look at the time between releases and the number of defects per release of WonderWidgets. If the time's too short then things are changing too fast to possibly keep up. If the time's too long then you may have a defect that wont be fixed for a long time. Same goes for defect rates. Bet accordingly.

• How active is the community around WonderWidgets? If there's a large active community with lots of people that can and do answer questions then this may help mitigate one of the previous bets. If not, you've got a bet.

• It's possible for open source software to just dissolve. You're always making a bit of a bet with these projects. (Yes, the same can be said for commercial software. And yes, there are ways to determine how big of a bet this is based on the size of the open source communitiy surrounding the project (ditto with commercial software)).

  For example, I was on a project where a bet was made on jStateMachine. The license changed and the developers got scooped up and are working elsewhere (or whatever actually happened). At the end of the day the team was stuck with a dead piece of software that was critical to the architecture. Luckily there were mitigating factors for this bet (i.e. an alternative).

I should point out that by no means is the list of bets static. It can and will change with time. You may add bets as they come up, remove some if they are proven false, and change the "size" of them (e.g. if the lead developer on an open source project that you're using was hired by a company that consumed most of their time, your bet for using the project just got bigger). Just keep a record of these bets. (No, this doesn't need to be some huge document that you need dedicated resources to maintain. It may be as simple as a "notepad" file that you keep on your desktop if in a small company / project.)

Looking at the bets, you should choose WonderWidgets based on your ability to find enough mitigating factors to make those bets tolerable. What's tolerable? It depends on the situation and the people involed. If you have a highly agile team (not necessarily in the XP sense of the word) then it may be able to adapt to a lost bet effectively in which case you can absorb and replace the loss more easily.

Just remember that you don't want to have too many components with large bets on them (mitigated or not). It may be fine to have a single large bet component if you have no other unmitigated bets. If you have a large number of components with bets (mitigated or not) ... look out! There may not be time for you to absorb losses from a number of lost bets. For example: You choose to use both jStateMachine and WonderWidgets. You mitigated each by having an alternative and by architecting the app such that you could "easily" place in the alternative. Both jStateMachine and WonderWidgets disappear (or have large bugs that are deemed "not important" or whatever). There's time and resources available to replace one but not the other. Now what? You made intolerable bets.

In order to keep teams happy and to keep up "innovation", I typically allow one large bet (with suitable mitigating factors) per project. This is tolerable for an average team.