Part 1. Dishwashing, coin-dropping, investing, and hemorrhaging
[This is Part 1 of my Quality and Productivity series].
For the most part, we tend to think about software projects as a sequence of tasks: we need to build the Whizz-Bang Widget, then the Decimal Doodad, then the Super-Service Subsystem.
Tasks have costs associated with them, for example monetary costs (often mostly from salaries), and time costs (from the passage of time as the programmers sit around earning those salaries while doing whatever on earth is is they do when they create those doodads). Both of these costs are linked to time.
If we want to become a bit more sophisticated, we can say that tasks have inter-dependencies: we need to do the Widget before we can start tackling the Super-Service. But mostly, the concern here is once again time: task B will have to wait for task A, which means time has to pass.
And for the most part, it seems to me like our industry acts as that what it’s all about: things need to be done, and preferably quickly. Most of of our project management meetings, and artifacts, and Gantt charts, and status updates, and Burn-down charts, and task estimation, most of our de-facto behaviour that an outside anthropologist would notice – it all seems to me to be focused on time: when can I have this done?
I’ll call that task-based thinking, and my aim here is to break that mold a bit.
For a start, not all “tasks” are the same. Over the past few years I started sorting tasks, in my mind, into categories which I’ll call Dishwashing, Coin-dropping, Investing, and Hemorrhaging.
The essence of the distinction I want to make is this: tasks have certain consequences – either good, or bad (or both), and these consequences play out over time, long after the task is done. I imagine those consequences as a graph with green or red lines, going off into the future.
Dishwashing
You could do the dishes sloppily, with a half-hearted rinse and wipe, or you could scrub them up like a surgeon washes his hands. But for the most part, once you’ve used the dishes again and washed them again, no trace of how well or how badly you washed them the previous time remains.
The shape, over time, of the consequences of Dishwashing type tasks are pretty boring. There’s a brief blip of goodness as the plates gleam and the kitchen is tidy, but by tomorrow the value of that single act of dishwashing is gone, for ever:
Dishwashing: value over time
An example of this in the programming world would be: you are developing on your system, and the app suddenly crashes. You guess it’s “that bug” again, the one that (you hope!) only surfaces in the development environment. So, instead of permitting yourself to get “sidetracked” by figuring out the source of the bug, you just do the proverbial reboot, or “make clean; make" so that you can focus on the task at hand again because you know by experience that will make the bug go away – for now.
I would call that type of thing dishwashing. Rebooting helped you now, but it did absolutely nothing to prevent “that bug” from biting you in the backside again tomorrow, and the day after that, and next week, and the week thereafter…
I saw another good example of dishwashing this week: I had a mole cut out, and afterwards the doctor sat in front of her laptop for 15 minutes to make up the account. First she had to add a line item for “consultation”, then for “anaesthetic”, then for “stitches”, then for “wound dressing”, then for “sterilising the pincettes”, then for “disposing of the scalpel blade”, and so forth. As she did this she apologized profusely: their accounting system can actually cope with adding categories like “mole removal” that break down into typical line items, so that they need only add the unexpected items to the account. But, she said, they haven’t had the time to get round to setting it up yet. Well, what she did was dishwasing: it helped to get my account done, but did nothing to help get the next patient’s account done.
Investing
Years ago you could have taken take a sum of money and invested it in Google; or you could have put the same money in Enron. A week later, you wouldn’t have noticed much of a difference, but by now you’d have noticed that the act of investing in Google just keeps on giving, whilst the act of investing in Enron gave you nothing.
The time-shape of Investing type taks is more interesting. The value may take a while to kick in, but thereafter it remains a constant (in this case, literally) presence in your life:
Investing: value over time (constant)
In the financial world, that’s a pretty atypical investment, one with constant returns. But examples of this in the programming world are not so rare: Imagine you make an improvement that shaves a minute off your total compile time, and imagine you do a full compile five times each day, on average. Then your act yields a constant daily 5 minute return on investment for each and every single day thereafter.
But, of course, non-linear return curves are also possible, and not just in the financial world:
Investing: value over time (exponential)
What would an example of this be in our industry? Imagine you run the some sort of online service, and you make your money off subscriptions. You spend a certain fixed amount of time to release an API which allows other people to write plug-in apps for your service. Imagine that causes a community form around your service, and every day the word of mouth spreads to more and more people, who subscribe to your service to make use of the cool plugins their friends are nattering on about. And then, the next day, they natter on about it to two other friends, and so forth,
Oh, and by the way: when you look at these graphs you may wonder what measure of time is represented by the X axis. Well, for now, my answer is: more than you think. If you thought I drew a graph of how the consequences of the action panned out over the next week, no. I drew the next month. If you thought I drew a month, no. It was a year. If you thought I drew a year, well, actually, you’re looking at a decade.
Coin-dropping
Thus far, I’ve only drawn green graphs. Now it’s time for the red.
If, for example, you accidentally drop a coin on the ground when you peek inside your wallet, that would be a loss, but at least when it’s over, it’s over. So coin-dropping is the mirror image of dishwashing:
Coin-dropping: cost over time
IT example: you lean back in your chair and accidentally kick the power switch. Computer off. Dang.
Or, you hit ALT-TAB once to many and get distracted a single session of reading Slashdot.
Hemorrhaging
Hemorhaging is investing’s evil twin. Instead of keeping on giving, it just keeps on taking:
Hemorrhaging: cost over time (constant)
An example of that in the computer world would be if you make a change that causes your system’s test suite to run 1 minute longer than before. For each and every day after that, your project loses (number of developers) × (number of test runs) minutes.
But here comes the stuff of nightmares: You get your running account and your credit card account numbers confused, and thereafter, you buy the office stationery, pay your electricity bill, run your company’s payroll, everything off the credit card. Not because you desperately need to stay afloat for just one more month until that huge contract you did pays out, no: just by accident. And then you only notice the mistake once the interest payments exceed your income:
Hemorrhaging: cost over time (exponential)
What would be an example of that in the development world? Well, for example, you choose to add something to your toolchain whose running time is O(n2) proportional to number of lines of code in your system. Today things are okay, but next quarter development is a bit slower, and next year ever worse, and five years later you institute a system where each developer has 30 PCs and rotates amongst them each day, so that she can continue coding on the changes she started compiling last month.