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”.

A hermaphrodite (or intersexed person) is someone who has some or all of the primary sex characteristics of both genders (for example, a penis and a vulva).

A young woman’s emotional health is on the line, and they can’t even bother to go to the trouble of getting good, up to date, information to balance the rumours!

The term “hermaphrodite” has fallen into disfavour. Virtually all of the people to whom the obsolete label applies find it offensive. On top of that, it is factually confusing and built on outdated knowledge.

A hermaphrodite is a creature that is fully and functionally male and fully and functionally female. Like an earthworm – for whom being a hermaphrodite is, of course, a totally natural state of affairs.

Now, I’ve got no problem with hermaphroditic sentient creatures, if such existed, and I’m sure their society would be very interesting and instructive. For all we know, they’d have support groups for the earthworms that turned out to be only male or only female.

But the fact of the matter is that us humans can’t ever be hermaphroditic. Even someone who, as in the Star quote above, has a penis and a vulva, does not have all the characteristics of both sexes. Due to having a penis, they lack a clitoris. Due to having vulva, they lack a scrotum. (I guess the closest you could come to a true hermaphrodite in humans is a male and female conjoined twin with a single upper torso and head – you’d need the two pelvisses in order two have two complete sets of genitals.)

More importantly, the obsolete “hermaphrodite” terminology just gets it plain wrong. At the time, the medical establishment was trying to salvage the notion that there really are only two human sexes. Which left them in the position of having to decide, in each and every corner case, which sex a baby really belonged to on purely anatomical grounds. They decided that the essence of sex is in the gonads – if you have any trace of testes you were a “male pseudohermaphrodite” (i.e “really a male”), if you had any trace of ovaries you were a “female pseudohermaphrodite” (i.e. “really a female”).

But by that reckoning, this would be a man:

Eden Atwood

That’s Eden Atwood, Jazz singer. She says she’s “…hard at work on “The Last White Horse,” [her] memoir that chronicles [her] experiences with [Androgen Insensitivity Syndrome] as well as [her] music and performing career”. You can watch a short ABC segment, including interview, here.

This would be a man too:

Melody, member of AISSG-USA

Now. Really. I know that the distinction between male and female is not always as simple as we’d like to believe (as these posts of mine attest). But to insist that these are men just because they have Y chromosomes would be like fighting so hard to preserve the simple binary male/female distinction that you’re willing to fight to the point of destroying it even in those cases when there is no grey in-between.

By the way, I suggest – tongue in cheek – that any men that disagree about the “grey in-between” and consider themselves obviously physiologically male without a doubt, go and have themselves checked out by ultrasound for internal uterusses and ovaries they had not been aware of. Just in case. Because it can happen, and has happened.

I could also point to the 1 August 2006 Consensus Statement on Management of Intersex Disorders from the journal “Pediatrics in review” that says:

Advances in identification of molecular genetic causes of abnormal sex with heightened awareness of ethical issues and patient advocacy concerns necessitate a reexamination of nomenclature.1 Terms such as “intersex,” “pseudohermaphroditism,” “hermaphroditism,” “sex reversal,” and gender-based diagnostic labels are particularly controversial. These terms are perceived as potentially pejorative by patients2 and can be confusing to practitioners and parents alike.

The article then goes on to advocate dropping the “hermaprodite” based terminology.

All these newspapers, going on about hermaphrodites. It’s obvious that the “experts” they consult, if any, are not really up to date, so one wonders how much effort they went to to find the “experts” in the first place.

It’s also obvious that the newspapers seem to think that Caster Semenya is such an oddity, that they never bothered to go search for support groups etc. of other, real, live people with other comparable conditions. Because if they did, they would have found out how problematic the term “hermaphrodite” was soon enough.

I know there’s this trope that scientific study is dehumanising. But for me, once I’ve read of, say, Complete Androgen Insensitivity Syndrome, about how a genetic mutation that makes cells oblivious to the presence of testosterone can make someone develop into a woman despite the fact that, as fetus, they developed testes, and once I’ve thought to myself: “Cool! How fascinating” – the people within whom these fascinating genetic events take place just become much more human to me.

Because there are fascinating genetic events in all of us.

Philosophically, I feel: for millenia we’ve been human without the slightest awareness of cells, or atoms, or chromosomes, or the like. Being human, male, or female, has never been about any of that stuff (except that we’ve had and still had the sad tendency let our notions of “male” and “female” limit our notions of “human”). For an extremely short slice of that time, we’ve known about X and Y chromosomes, and that XX makes women and XY makes men. And soon afterwards, we’ve discovered that er, no, it’s not always that simple.

Seen from this perspective, it almost feels just as silly for, say, a CAIS woman to be bothered by the fact that she has a Y chromosome in her, as it would be to be worried about the fact that you’re made up of electrons and quarks. From the perspective of our humanity, our hopes, dreams, friendships and relationships, all of that stuff under our skins is, in a way, abstract and irrelevant.

When I just wrote that, it seemed like a contradiction to me – superficially at least. On the one hand, I am intensely interested in the precise scientific details of these things. On the other hand, I say they are irrelevant to our humanity.

I think Alice Dreger (whose writing I on these things I strongly recommends) sums it up well:

I keep running into smart people who seem to think I believe that sex “isn’t real” because it is all “socially constructed.” Allow me to correct this erroneous social construction of me by summarizing here what I think about sex and gender. I’m tempted to say “what I know about sex and gender” because there are few things I feel as sure about as this.

Testes are real. Ovaries are equally real. They sometimes make real gametes. (I don’t mean to imply they sometimes make fantasy gametes—just that they sometimes don’t make gametes.) Chromosomes and genes are also real. As anyone who’s every forgotten to wear a pad on the right day knows, menstrual blood is real. To the delight of this straight woman, penile erections are real. So are clitoral erections. I’m equally delighted about those.

When I say these are “real,” what I mean is that these things have a material existence independent of our ability as humans to notice, study, deny, politicize, or categorize them. I can’t believe I even have to assert this claim, but some academics have gone over the deep end and disagree. (I don’t hang out with such people unless there I have some form of pain killer at the ready.)

…Nature doesn’t care that we humans tend to like discreet categories. The real world is messy.

And whilst we ponder and agonize over the mess, all of the cells, genes, chromosomes, gametes, quarks, leptons, protons etc. in our body quite happily continue being us, quite oblivious to all our wrangling about how they ought and oughtn’t go about the business of being us.

I’m not no red football
to be kicked around the garden
No no

Red Football, Sinéad O’Connor

As I watch the tragic farce of the Caster Semenya’s sex verification debacle unfold, I feel sorrow for her. What must it feel like for her to learn, in such a publicly humiliating spectacle, that she has testes hidden inside her?

One small piece of good news in all of this is that apparently someone finally saw fit to give her access to professional trauma counseling. I just sincerely hope that those counselors are well and truly independent of those bastard organisations that put Caster in this spot in the first place.

As the sex row washed over our newspapers, like a weeks-long slow-motion crash test, I’ve learnt a lot more about the many ways in which human sex and gender is só much more intricate than our simplistic notions would suggest. (Not from the newspapers though – their reporting is generally atrocious).

And I feel a growing sense of outrage at the paternalistic, daddy-knows-best, keep-em-in-the-dark way these people have been treated.

It’s a recurring theme: well into early adulthood, pediatricians, gynaecologists, parents, deliberately lie to someone about exactly why doctors are so concerned about their nether regions. People giving consent to surgery to have their “twisted ovaries” removed – only to find years later in life that they never had ovaries in the first place, and that “twisted” was an euphemism for “your ovaries were testes, girl”.

I know a lot of this is motivated by a desire to protect these children with atypical sex development. But what I read from the adults who emerge on the other side, it just doesn’t work. They know there’s something different, they know it’s not normal to have genital surgery every few years, to have countless hormone therapies – and the fact that no one will tell them what and why this is happening to them just makes them feel isolated and lied to. That’s a recurring theme: for many of these people, having been lied to and operated on without their knowledge and consent is the bigger pain – not so much the fact that the have unusual sex organs.

And amongst the shameful treatment of Caster, I see echoes of that same paternalism. The fact that Athletics South Africa saw fit to do a secret sex verification means that someone there very well suspected that she had some or other intersex condition. The fact that they did it under false pretenses, and didn’t involve her in weighing the risks of competing internationally versus having her sex questioned on the world stage, just feels like gambling with an innocent teenager’s psyche.

As an aside: how the heck does one do the intensive kind of sex verification they did surreptitiously, any way? “Ok, girl. The first part of your drug testing was when we took blood. That was to test for steroids. The second part was when the psychologists kept asking you questions about whether you feel more like a man or a woman. That was, ahem, er – to test for cocaine. Now, for the next part, we now need you to get in the stirrups so we can photograph your privates, so, er, we, um… it’s all Science my dear, just trust us!”

Lastly, I am outraged at the cowardly way some of the officials involved try to hide their mistakes. “The South African constitution forbids us to do sex testing, and that’s why we had to send her off to Berlin without warning”. Yeah right. The constitution forbids discrimination on the basis of sex or gender. How do you leap from there, to the notion that the constitution forbids the consensual diagnosis of sex-related conditions, or forbids psychological counseling to help a teenager learn and understand why that diagnosis might need to be sought in the first place?

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:

Benjaman Kyle, as he chooses to call himself, was discovered, naked, sunburnt, and apparently severely beaten up, behind a Burger King in Georgia, USA.

And at that point, around 50 years of age, his life began.

The pseudonym he chose for himself fascinates me. Why the “Benjaman” instead of “Benjamin”? Is there some suble wordplay going on? He’s not Everyman, he’s Benjaman?

But then, even if he had chosen to go by the name “Zorgle Weeblebrodskni” if would consider it fair to let him live under that name, legally. Who knows what deeper meanings a self-chosen name has for someone with no identity otherwise?

Yet, there’s something sad to the name choice as well. Because the banal detail of having been “born” behind a Burger King seems to cling to him. The nurses took to calling him names like “BK Doe” – all plays on Burger King – and when he chose a name for himself, he apparently could not move away from the BK either.

And how’s this for poignancy?

He spends most of his days – when not working odd jobs – searching for himself on the internet and in newspaper articles.

Benjaman, if you Google this: I wish you luck.