Pieter Nagel: Swapping Thoughts

[This is Part 2 of my Quality and Productivity series].

In the first instalment of my Quality and Productivity series, I introduced a particular way of looking at something like a software development project:

Instead of thinking of the project as a sequence of tasks to be completed, each of which costs a certain amount of time to complete, think of it this way: a project is a series of actions, each of which has short-term and long-term consequences. You can visualise these consequences as a green (positive) or red (negative) graphs with a certain shape (brief spikes, flat lines, or exponential curves) extending far off into the future.

This brings up an important corner case: none of what I’m trying to explore in this series has any relevance if the project is not intended to have any future at all. If the explicit plan is that the project should fail, or terminate in the near future, then by all means feel free to excuse yourself from this discussion.

Today, I want to play a bit with the conceptual vocabulary I’ve established. So, let’s combine some of our concepts:

In the above hypothetical scenario, a project took an action and derived some immediate short-term but short-lived benefit from it – the green spike. But the cost, or consequence of the benefit was an ongoing an increasing recurring detriment. Continuing in the same vein as in my last installment, one could call this “selling your soul to get the dishes done”. Don’t try this at home.

However, since no-one on earth would be so crazy as to do this (I hope), let’s move on to a potential permutation that’s a tad more realistic:

In this case, the same short-term benefit was gained, but this time at a much lower cost: specifically, a small but constant ongoing cost.

The red part of the curve is more realistic, since it’s not unheard of for things to have ongoing constant costs – if you employ someone, you have to repeatedly pay them a salary for the foreseeable future; if you add a feature to your codebase, you will incur a small but repeated cost to maintain that feature in the face of framework upgrades.

However, the green part is still a bit atypical: usually software is developed in order to gain an ongoing benefit, such as clients paying fees for the services the software enables.

But I first want to pause here a bit.

Readers may suspect by now that I’m getting at the topic of trade-offs of long-term vs. short-term costs and benefits. So, they may guess that I’m heading towards saying that ongoing long-term cost will eventually negate short-term immediate benefits. Well, I thought that I was driving towards that point.

So, let’s introduce another concept: You can think of the state of your project today by stacking up all the graphs of all consequences of all past actions. Projects don’t consist of single actions, they consist of a multitude of actions, week-by-week and day-by-day. Each action has its own consequences; each of those consequences could potentially be good or bad, short-lived or long-term.

Now let’s explore what would happen if one made a habit of this hypothetical business model of getting short-lived benefit at constant long-term cost:

Well, ok. So the ongoing costs keep getting bigger and bigger. But hey – they do manage to get a nice ka-ching! in the cash register at regular intervals.

It is at this point, I guess, that some astute readers are really getting irritated with me. What’s with the silly green and red distinction between costs and benefits? Why don’t I just simplify my model by adding them up and talking about nett costs and benefits?

I must admit that my inner mathematician made the exact same objection, and it took me a while to figure out why I instinctively wanted to keep the red and green separate. But I kept them, and I have my reasons.

But for now, let’s acquiesce, and replace the above with a nett graph. Better yet, let’s graph the cumulative costs and benefits accrued over the entire lifetime of the project:

Hey, that doesn’t look to bad! We’ve got a realistic cost model and a hypothetical pessimistic benefit estimate (only once-off short-term benefits), and even then the nett benefit seems to go through the ceiling. Maybe this model is sustainable after all!

Even I was stumped for a while, since my I set out to show that the hypothetical model is not sustainable.

And that’s where will pick up from in the next installment.

Agile Development