I have been working on the same system for almost 12 years now, and I have watched its lifecycle from cradle to the grave. In that time I have done a lot of soul-searching about balancing short term against long term considerations. Looking back, I have realized that these two poles of thinking are often embodied by two types of people in programmers’ lives.

Championing the cause of the “short term” end of the scale, one often finds mostly lower to mid level managers – the Project Managers in whose lives it is a disaster if Feature X would slip to the 15th of February next month instead of the 7th. Who  feel strong pressure to make that happen, and will pass that pressure on to the team.

Often, those deadlines are there for a sound reason: missing the demo at the yearly trade show, missing the deadline for implementing a new tax regulation, or announcing a project to the market with great fanfare and then not making it can all be seriously damaging to the company as a whole.

But just as often those deadlines are more arbitrary. If they slip somewhat, one meeting of a steering committee might be a bit heated, and contingency plans that had anyway already been decided on may be put into action, but few people outside the steering committee may even know.

But on the other end of the scale, one finds the people who have a larger stake in the company as a whole:

I remember an after-work conversation with our CEO, during her smoke-break, where she said, almost pleaded, that something needs to be done about the speed of development at our company that was slowing down. She wasn’t primarily concerned about Feature X, or Feature Y. She was concerned about whether development by the end of the year would be more productive than last year, because with a downward trend the company itself would not remain viable at all.

I remember the Christmas year-end function where the investor that founded our company, and still carried it, pulled me aside to tell me the same: something had to be done about the speed of development. Little did he know – or perhaps he did – that I had already been trying to champion that cause “from below” for quite some time, and that short conversation we had gave me a lot of the boldness I needed to face the obstacles I perceived.

Often there is a large disconnect between these two groups of people, and over the long term (ha!) this does great damage to companies.

Short term concerns, such as hitting a laundry-list of goals on set dates, require one set trade-offs if they are to be met. More meta-level concerns, such as whether the company itself will remain in the position, year after year, of even playing the game of hitting laundry-lists of goals, require very different trade-offs.

Whenever you have opposite goals that are in tension, you can only successfully navigate the trade-offs if you actively manage and track all of your goals. Suppose you want to design an aeroplane that is both lightweight and cheap and strong. But imagine you only ever ask the team for feedback on the price, rarely talk to the team about its weight, and never mention the strength. Surely it would be madness to assume that you will just magically get an aeroplane that is anything but cheap at the expense of being too heavy to fly and to weak to remain in one piece?

But it seems that most development organisations seem to manage their long term goals by just assuming that if everyone fervently works towards the short-term goals, and keep on doing so for year after year after year, that the long term goals will just automatically be met.

And all around me I see the same phenomenon: companies that find themselves in crisis, because development is slowing down to a crawl, after five, or seven years or so of taking shortcuts. Companies that are unsure whether they’ll even be able to continue competing, or whether they need to abandon the entire product line and seek different markets.

If companies care about both the short term and the long term simultaneously, they need to put people and processes in place that champion both, and make sure these are felt at all levels of the company.

But all around me I see teams of programmers, who feel the Project Managers breathing short-term concerns down their neck day in and day out. But who not even once get to have that conversation with the CEO at her smoke break, or the company funder at the Christmas party.

I guess that it is the “not overloading the developers” bit that she is sceptical about.

I can’t vouch for her employers, since anything that becomes a buzzword is at risk of half-baked implementations by people who don’t get it. But since I had great success with instigating Kanban at my previous time, and not just the CEO but the developers themselves were also pleased, I do feel I have to come to the defense of Kanban itself.

The essence of Kanban is to get to know one’s development system so well as to know where in the process the current bottlenecks are. And then, to try and increase productivity not by trying to run that system beyond its maximum capacity, but rather by improving the system itself so that the bottleneck is no longer a bottleneck.

That means running the system at no more than its current capacity. The people who are responsible for the current bottleneck tasks should feel a reduction of stress, since they are no longer asked to exceed their current capacity by sheer sweat and willpower alone.

Everyone else, who is not a bottleneck, should suddenly have a lot of slack on their hands – and this is by deliberate intent. It might seem like an anathema to Matrix Managers to have “resources” such as Business Analysts working at less than 100% capacity, but since developers have a limited capacity, it would be a wasteful exercise for Business Analysts to draw up more specifications than the developers could ever realistically code up.

The slack that is freed up is instead used to improve the current development process so that the current bottleneck is no longer so, at which point those people get their turn at being the ones with slack and other people get to be the bottleneck

For this Continuous Improvement “Kaizen” culture to really take hold and be really effective, you need to have a few elements in place:

• You need to take a broader view than just development. Instead, you must look at the business as a whole as a complicated system of its own, starting at the point where someone dreams up new requirements, and following it right through to the end where the completed requirements actually deliver some real-world value to real-world customers (an income to the company).
• You need the right personalities to champion this improvement, who can keep on providing the emotional energy and impetus to stick at it. This is especially important in less healthy company cultures where trust has been lost and employees are jaded.
• You need empirical information on how your current development processes are really functioning, as opposed to pie-in-the-sky ideas on how you fervently believe things are currently going. This is why Kanban has a strong emphasis on process visualization.
• You need theories to help you come up with hypotheses as to why the current system is inefficient, and how you could improve it. For this, Kanban makes extensive use of the Theory of Constraints, and the Lean Principles that originated from the Toyota Way.

All this is pretty abstract and philosophical. What makes Kanban so successful is that it provides extremely simple and easy to understand principles to help drive the aforementioned as emergent properties: Work-In-Progress (WIP) limits, and Pull Scheduling.

WIP limits refer to the notion that it is actually not a good idea to have too many irons in the fire at the same time. In other words, everyone should have a limit on how many different things they are busy with at the same time. At some point, before you can start with something new, you have to finish something old.

In general, lower WIP limits are better. If you find yourself blocked and unable to proceed on any of your current WIP tasks, that time is better spent investigating and alleviating the root causes of that blockage.

Pull Scheduling refers to the practice of not “pushing” new work to downstream people. Instead, people pull new work for themselves from upstream processes whenever they have completed something and their WIP limits allow them to start with something new.

This preference for completing old work instead of starting new work has the nice morale-boosting side effect that one tends to complete something tangible at regular intervals, which makes one’s work-life feel more and more like the regular hitting of milestones, instead of like one long death march after the other.

This has the salutary side effect of driving greater maturity when it comes to prioritisation of tasks. Instead of asking developers for everything and the kitchen sink, and padding those requirements with more nice-to-haves because development takes so darn long that you could just as well try and get everything out of your 18 month cycle that you can, management now has to focus on “what is the single most valuable thing I can have my people working on next, when they finished with what they’re doing now?”.

Finishing that “single most valuable thing” first before starting something new has the nice side effect that the business can start accruing the value of completing it immediately, instead of having to wait for the other bells and whistles to be finished. Furthermore, the decision whether to do the other bells and whistles at all can be informed by experience with having the core functionality already out in the field.

The transitional period was, of course, a bit stressful. The go-live date of the new arrangement coincided with a very important company milestone for which all kinds of new features had to be developed, and so as part of their learning curve for taking over the web codebase, ALFI also had to crunch to get features out on time.

This meant that ALFI had all kinds of urgent queries about the API, or discovered all kinds of unfinished corners of the API, which PSP had to change for them. But now PSP’s two-weekly planning cycle was too onerous, because ALFI could not afford to wait until the start of the next cycle, then wait two more weeks for the change to be deployed, and then only start developing on their side of the API.

So PSP decided to make some “temporary” changes to their development cycle for ALFI’s sake. Critical new development tasks and bugfixes were allowed to be scheduled mid-cycle. Instead of deploying at the end of the cycle, PSP would deploy point-releases at regular points during the cycle.

This took a large toll on PSP. Deployments had an extremely high transaction cost associated with them: the automated validation of schema integrity would take hours to run, which means that the feedback cycle on bugfixes related to that was extremely slow. I would not be surprised if a lot of overtime was spent waiting for such feedback, and then fixing the issues. Once the data integrity was clean, deployments themselves could sometimes take a few hours of two employees, and this also had to be overtime so as to keep the system running during business hours.

Given that deployments happened once every few days, employee burnout must have been high.

Now, I am sure that PSP believes that this was a temporary state of affairs, and that as both companies adjust to the new situation, they would be able to incrementally re-assert their old two-weekly planning cycle.

But let’s just quickly look at the big picture:

ALFI entered the new arrangement due to dissatisfaction with the latency associated with the two week cycle, in the belief that they would then be able to help themselves with changes to the website without waiting on PSP.

But now, whenever ALFI wants to make changes to their front-end that need changes to PSP’s API, they need to first wait for the start of the next planning cycle, the wait two weeks for the changes to be developed, then wait for their own developers to code to the new API.

Is it likely that ALFI would be satisfied with the overhead on crucial features if they had not been satisfied with the overhead on changing marketing boilerplate text before?

It seems obvious to me that, far from PSP settling back to their old routine, they have now inadvertently helped to unleash forces that will keep on hammering away at their two week planning cycle. And either they will need to give in, or both they and their client will need to create ever more elaborate planning workarounds which will lead to increasing customer dissatisfaction.

Worse yet, at some point YALFI will also start developing their own front-end, and so similar forces will grow to act on PSP from that side.

I doubt that their two-week planning cycles will long survive these forces, no matter how hard and how faithfully they wish to cling to “doing XP the original way”.

What they need is a way to adapt to the new realities, instead of resisting them, without burning themselves out, and without relinquishing their core Agile values.

And for this, I think they would be well served by considering adding Kanban influences to their mix.

A Large Financial Institution (ALFI) has been using their Preferred Solutions Provider (PSP) for quite a few years. PSP wrote the system that manages the financial products that ALFI provides, as well as the web front-end through which ALFI’s clients could interact with their investments.

PSP manages this relationship in a strict Extreme Programming style, which means they run two week long development cycles, and ALFI can request some amount of Story Points worth of new work to be done during a planning meeting at the start of each of these iterations.

This implies that each such cycle has a fairly high transaction cost at its start: the planning meeting, during which PSP’s developers would presumably need to be present to estimate Story Points for each task. This ritual seems to take a half to a full day, or about 5%-10% of their development capacity.

But the real cost lies in the latency: each new requirement would have to wait until the next planning meeting, and then for the end of the iteration, or in other words at best between 2 – 4 weeks between desire and fulfillment.

At some point it was decided that the development of the web front-end would move in-house to ALFI itself, and that PSP would merely provide an API through which the back-end system could be accessed.

Both parties seemed to be pretty keen on this arrangement, each for their own reasons:

• ALFI was dissatisfied with the overhead to their requirements, especially in cases like when their Marketing Department wanted to tweak the text on their website, but had to wait 2 – 4 weeks for this to be delivered.
• PSP had started to reposition their system as an engine that serves multiple clients, and if they no longer needed to develop ALFI’s front-end, that would also imply that they would not need to develop a front-end for their new client, Yet Another Large Financial Institution (YALFI), either.
• PSP felt that the front-end was not their “core competency”, or, as I would paraphrase it in more technical terms: they didn’t like doing web development and wished to have it out of their lives so they could “focus” on the core system.

And so it was decided that PSP would hand over the source code repository of the web front-end to ALFI.

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.

Today, I am not going to comment on how suitable either TCL or C is for the job. I will take it as a given that, TCL is the wrong tool for the job and that C is the right tool for her to use – in her specific context. Because, of course, she and whichever reasons make her prefer C is an important part of her specific context.

However, I do want to comment on the “rewrite” bit. Rewrites are fraught with risk and are almost invariably more complicated that anticipated. See, for example, Uncle Bob on The Big Redesign in the Sky.

I’ve lost count of the times when I’ve had to make a “small” change to our system which we thought would “obviously maintain existing semantics”, only to find that the big bold leap to the new algorithm doesn’t work. In those cases, it has been of great value to retain both the old and the desired new implementation simultaneously, add asserts to our code that verify that both algorithms yield the same result, run the whole test suite, and let the computer pinpoint the fallout. Fix test failures, lather, rinse repeat.

And all that in the context of a small modification within a single existing system! I shudder when I contemplate the notion of trying to create a whole second system from scratch.

Luckily, there are better ways than a blank-slate rewrite. One option is the “Strangler Pattern” Martin Fowler described (also know as the “Strangler Vine Pattern”). The basic idea is to wrap the new system around the old system, siphon off more and more of the external-world inputs to the new application, until the new application replaces the old. Somewhat like a strangler vine replaces the tree it parasitises for scaffolding.

But there is another alternative, which I would call the “Grandfather’s Axe” pattern:

As the proverb says: “This is my grandfather’s axe: my father fitted it with a new stock, and I have fitted it with a new head.”
—Robert Graves, The Golden Fleece, p. 445

If you replace all the parts of something one by one, is it still the same thing at the end? Or think of Theseus’ Ship of Greek legend, which slowly, over time, had all its’ planks replaced. Is it still the same ship?

Lost argonauts, recently spotted in the present-day incarnation of Theseus' ship.

Instead of building a new system around the old one, replace parts of the old system one by one until only the new system remains. In the Strangler Pattern, the new system gets control before the old system does, and in that way intercepts more and more functionality. In this pattern, each part of the new system gets control at exactly the same point as the old part did, and functions within the context of the old system.

So, I would advise my friend:

1. Install something like SWIG.
2. Choose a simple, self-contained TCL function without dependencies to the rest of the TCL system. Reimplement it in C.
3. Figure out how to get the old TCL code to call the new C function.
4. With the mechanics of SWIG and TCL to C integration under your belt, next time you need to maintain a TCL function, try to move it to C first before extending its’ behaviour.
5. Repeat until no TCL is left. This is the crux: if there’s no will to see if through, one is left with a more complicated system than one started off with.
6. Discard the SWIG scaffolding.

One need not end up with a straightforward C port of the original system this way. As more and more of the system lives in the context you prefer, it should be easier to mould that part of the emerging new system into a new shape. That’s the premise: that the code is so much more expensive to maintain and modify in TCL that it would be cheaper and easier to modify it in C. If this premise isn’t true, there’s no point to this exercise.

Since the essence is to gain maintainability, I would also strongly advise taking the opportunity to explore Test Driven Development to bring the nascent new system under automated testing and gain a better handle on maintaining it.

However, I do feel compelled to point out that personally, I would never choose to move towards C in this way. I would use this technique to move away from C toward something like Python, Ruby, Lua, Scala or the like. Or, if appropriate, I would use this technique to isolate the speed-critical code into C subcomponents and the rest into a more malleable higher-level language – also known as the Alternate Hard and Soft Layers pattern.

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.

Over the past ten years I have been working as part of a team of developers who work on a single software system.Ten years is not exceptionally long, but I do suspect that it is much longer than the average time most programmers remain involved on a project.

In that time, I’ve gained some experience that I feel has given me a different perspective about many of the decisions and trade-offs we make day to day- because I’ve seen the long-term effect of many such decisions.

In short: I vociferously agree with the Agile and Lean dictum that to increase productivity, one needs to increase quality. Or, the converse: that cutting corners and lowering standards in order to get work done faster is a surefire recipe for decreasing productivity – bogging it down..

Nothing new there; nothing that W. Edwards Deming, the Lean movement, Kent Beck, the signatories of the Agile Manifesto, and may practitioners in my own and other industries haven’t been saying in their own way for the past few decades.

But I find that I’ve grown to think about these things in ways that make it difficult to communicate with people who don’t share the same mental framework. More importantly: I find myself curious about what exactly my own mental framework is: I write it down for my own discovery more than anything else. In my mind, it feels like what I will write in future will be something akin to deriving a lot of the values and rules of thumb of the Agile world “from first principles”, as’t were, because it all “clicks together” in my head in a way I wish to share.

The outline as I anticipate it so far:

• Part 1. Dishwashing, investing, and hemorrhaging.
• Part 2. Selling your soul to get the dishes done.
• The fallacy of “task-centric” thinking.
• Ticking off a to do list, or making repeating appointments?
• Cognitive bias: project mistakes we’re hard-wired to make
• Over time, most systems tend to become absolutely dominated by long-term negative effects of short-term decisions.

Say, for example, my swimming pool is cloudy. I’ve already checked the acid, chlorinator, etc. so I surmise that the problem is that the pool is full of a little suspended particles – underwater dust, as’t were. Lots of Gautrain construction in my area, so that’s no wonder.

No problem. I know exactly what I need and what it’s called: a flocculent. The particles are so fine that they never settles to the bottom of the pool, where the Barracuda can suck it up. But a flocculent is a chemical that will make them stick together into larger clumps, that will sink and be caught by the filter.

Off to the shops, then.

I innocently and straightforwardly ask the shop assistant “where do you keep your flocculents?”, and I get punched in the face almost as hard as that time I told the petrol attendant “I want ethylene glycol” and he yelled at me: “I don’t care where you want her, pervert, you stay the HELL away from my wife!”

No, I lie. Today is a good day, the shop assistant just gives me a blank stare. For some reason they often give me blank stares when I ask for things.

So I just tackle the shelves myself. There’s rows and rows of Sparkle-Brites, and WonderBlues, and SuperClears – and SuperClear Plusses. Hmmm. On closer inspection, none are subtitled “WONDERBLUE flocculent” or the like, so a deeper inspection is warranted.

I turn the bottles round, expecting to find some marketing shpiel to the effect that “SuperClear is a superior flocculent that has been lovingly developed in our high tech labs in order to…”. Nothing. Nada.

What I do find is lots of promises that WonderBlue will make my pool wonderfully blue and clear, or that SparkleBrite is an essential part of every pool-owners poolcare regimen. Of course, I read the exact same statement on all the chlorine, all the Hydrochloric acid (pardon me, Pool Acid), Cyanuric Acid (oops, I mean Stabiliser), and algaecide (sorry, that would be “underwater disinfectant – kills blue-green pool-germs DEAD!”).

What to do?

If I’m lucky, the back of the product will at least say “… cleans the pool by making tiny particles that cloud your water sink to the bottom, where they can be sucked up by the automatic pool cleaner”. Then I can reasonably safely guess they mean “flocculent”.

If I’m less lucky, the back will read “…helps your pool filter clean the water better”. Then I can make a somewhat more cautious guess that they mean “flocculent”.

Alas, I’m left trying to guess whether a flocculent is most likely to be a powder, or a liquid, or a gel. Why can’t they just label their products with a description of what they actually are?

As it stands, I can just buy the damn things and see if they act like what I hope they are.

Which is, I guess, what the average consumer does, anyway: buy lots of stuff until they find something that works (because it complements their particular habits for neglecting certain pool chemicals), and then swear by that as the be-all and end-all of ultimate poolcare.

In a future installment, I shall relate my adventures when trying to purchase vulcanizing glue for a hobby project, and how the helpful shop assistant pointed me to “a theatre make-up shop where other that can help Star Trek fans like you”.

The following video show one such rescue of a horse that fell through a frozen pond. I found it quite nail-biting to watch, so for the sake of my horse-loving readers, I’ll give a spoiler: it all ends well.

Untamed and Uncut - Horse Gets Trapped Under Ice

The poor horse is in visible distress. Every time she does manage to wrestle her forequarters onto solid ice, the ice just cracked right out from underneath her and the she was dunked back into the frozen water. That seemed to make the horse just despair and dismay; at times she seemed ready to give up and die.

I find the technique the firemen used to traverse the ice fascinating: the laid down lots of ladders flat on the ice, then walked on the rungs of the ladders, instead of on the ice. In that way, the ladders become a giant snowshoe spreading their weight. I wonder of this is a common trick for ice rescues?

However, the firemen seemed obviously ill-prepared for the sheer size of the horse, and although they did manage to rescue her in the end, the way the handled her seemed very ill-prepared. It just seems wrong to try and haul a horse’s entire weight by a lasso around her neck.

It seems the firemen needed  some  Technical Large Animal Rescue training:

Trained horse demonstrating how to be rescued

But the following photo just puzzlez me:

This looks like something that would have the SPCA on your case

I can understand that rescuers will often only be able to use a less-ideal technique for harnessing a horse, but is the demonstrated technique really a viable way for dragging a horse by its tail? Or am I missing the purpose?

The whole thing of “horses falling through ice” seems to happen fairly regularly: