We often hear the proposal that dependencies are bad, and we should work to remove them.
Is that true? Well - it ... depends. Pun intended.
First and foremost, "dependency" can mean many things, and some of these are good, others bad, and some conditionally good or bad - and yet others, simultaneously good and bad.
Before I get into that, let me define what I mean with "good" and bad:
(You can skip this section if you can simply live with the terms "Net Benefit", "ROI" and "TCO".)
Looking from an economic perspective, anything we do or decide results in an outcome.
This outcome has a benefit - the Return on Invest (ROI).
The way to reach this outcome, its maintenance and failures on the way all have a cost - the Total Cost of Ownership (TCO).
From that, we can determin the Net Benefit: ROI - TCO.
Whether we measure that in Currency (Dollars/Euros) or in whatever unit we see fit (e.g. time, opportunities, satisfaction etc.) is irrelevant. Every outcome we get has such a net benefit.
As such, we can always compare two alternatives based on their net benefit. The outcome with the "better" net benefit is the preferable option.
Either we can:
- do the yard work this Saturday, and have a clean yard.
Net benefit = clean yard.
- hire a gardener at $500 to do the yard work, and go to see the Playoffs.
Net benefit = clean yard + seen playoffs - $500.
Now, whether you prefer option 1 or 2 depends on whether you value attending the playoffs more than the $500, so often, the Net Benefit may have some subjective component that's hard to quantify in money. Regardless, a rational mind would choose whatever option has the highest subjective net benefit.
Why do I bring up this example?
Because option 1 has no dependencies, and option 2 has a hard dependency on the gardener and on the money. If you prefer option 2, you deliberately choose to have a dependency in order to increase your benefit.
Good and bad dependencies
Option A, which has dependencies and Net Benefit A as "ROI A" - "TCO A".
Option B, which no dependencies and Net Benefit B as "ROI B" - "TCO B".
To at least keep it somewhat simple, we'll assume "risk" (of whatever type) is part of the TCO.
This gives us a proper basis for discussion.
|Bad dependency||Net Benefit A < Net Benefit B,
TCO A > TCO B and
ROI A < ROI B.
|Being unable to meet market demands
because a component vendor can't keep up.
|Good dependency||Net Benefit A > Net Benefit B and
TCO A < TCO B.
|Software company buying servers
instead of building chipsets from raw silicone.
|Potentially good dependency||Net Benefit A > Net Benefit B but
ROI A < ROI B.
|Letting a business partner serve a market segment
you're not an expert in.
|Potentially bad dependency||TCO A < TCO B but
Net Benefit A < Net Benefit.
|Preferred Supplier process that simplifies procurement
but means you can't get everything you need.
|Mixed dependency||Net Benefit A > Net Benefit B and
TCO A > TCO B.
|Outsourcing sales to an agency
that takes a commission.
That clarified, we definitely want to avoid or eliminate "bad dependencies", but we may actively look for "good dependencies".
What happens in practice, though, is bias: we inflate ROI and discount TCO to make dependencies look more rosy than they are. We do this by making overly optimistic assumptions about potential payoffs (ROI) and dismissing negative factors that don't meet our concept. Of course, that is a trap we easily fall victim of and we should make sure we draw a realistic image on both ROI and TCO, preferrably erring on the side of caution.
Now, let's take a look and interpret those dependencies:
A bad dependency is definitely something you want to eliminate. You win by removing it, hands down.
Don't be fooled, good dependencies are both everywhere and at the same time rarer than you think!
Our specialized service society is full of them. They help you make the best value of your own scarce resources, first and foremost, time. We could hardly live if we wanted to have no such good dependencies. You depend on a farmer to produce food, you depend on cars or public transportation which you haven't built, and so on. The modern world wouldn't be able to exist without them.
To eliminate such good dependencies would throw us back into the Stone Age.
After this, let's take off the rosy glasses and face reality: willfully induced good dependencies can turn sour any time. To use an illustrative example, let's say you're a non-tech company who decided to outsource their IT to an IT Service provider. Then, the market turns and your most profitable segment becomes online sales - all of a sudden, your ability to meet market demands depends on an external agent who now dictates the rate at which you're earning money!
Potentially Good Dependencies
The world isn't simply black and white, and TANSTAAFL. Partnerships are a great example of a potentially, though not universally, good dependency. In our above example, the dependency is good if you partner with someone who relieves you of some burden to allow you to achieve more. The dependency is bad if you partner with someone who allows you to achieve more, but at a price you can't really afford.
(An extreme example here might be a model who becomes rich and famous through a casting show, but is forced into a contract that ultimately makes them sacrifice family relationships and health.)
Potentially Bad Dependencies
When you can have something simple cheaper than something better, that's good if you are content with the outcome. It's bad if you aren't. Since most of the time, people want the best possible outcome, these types of dependency are usually bad.
How does all of that map to "Agile"?
We have to make a clear case that a discovered dependency is bad.