Goalodicy – the pursuit of idiotic goals
The last book I read was Scott Adams’ “How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life“. The current book I’m reading is Oliver Burkeman‘s “The Antidote: Happiness for People Who Can’t Stand Positive Thinking“. Coincidentally, and unbeknownst to me before I began reading the books, both authors trash the dogma that setting specific goals is a worthwhile idea. Burkeman has this (and much, much more) to say on goal pursuit:
A business goal would be set, announced, and generally greeted with enthusiasm. But then evidence would begin to emerge that it had been an unwise one – and goalodicy would kick in as a response. The negative evidence would be reinterpreted as a reason to invest more effort and resources in pursuit of the goal. And so things would, not surprisingly, go even more wrong…. There is a good case to be made that many of us, and many of the organisations for which we work, would do better to spend less time on goal-setting, and, more generally, to focus with less intensity on planning for how we would like the future to turn out. – Oliver Burkeman
Scott Adams is even more critical of the “best practice” of goal-setting than Burkeman:
Throughout my career I’ve had my antennae up, looking for examples of people who use systems as opposed to goals. In most cases, as far as I can tell, the people who use systems do better. The systems-driven people have found a way to look at the familiar in new and more useful ways. To put it bluntly, goals are for losers. That’s literally true most of the time. For example, if your goal is to lose ten pounds, you will spend every moment until you reach the goal—if you reach it at all—feeling as if you were short of your goal. In other words, goal-oriented people exist in a state of nearly continuous failure that they hope will be temporary. That feeling wears on you. In time, it becomes heavy and uncomfortable… Goal-oriented people exist in a state of continuous pre-success failure at best, and permanent failure at worst if things never work out. – Scott Adams
If you’re a laser-focused, SMART goal-oriented person, you might want to revisit some of the foundational bricks in your worldview in light of what Burkeman and Adams have to say. But then again, neither Burkeman nor Adams are absolutists. They don’t emphatically advise against all goal-setting. They simply suggest considering alternative, less psychically destructive methods of attempting to better our lives (devise/use a system; envision a qualitatively desirable future and move toward it).
You might say every system has a goal, however vague. And that would be true to some extent. And you could say that everyone who pursues a goal has some sort of system to get there, whether it is expressed or not. You could word-glue goals and systems together if you chose. All I’m suggesting is that thinking of goals and systems as very different concepts has power. – Scott Adams
There is plenty of very real research testifying to the fact that the practice (of goal-setting) can be useful. Interpreted sufficiently broadly, setting goals and carrying out plans to achieve them is how many of us spend most of our waking hours. – Oliver Burkeman
Work started (on the 503 Mark II software system) with a team of fifteen programmers and the deadline for delivery was set some eighteen months ahead in March 1965.
Although I was still managerially responsible for the 503 Mark II software, I gave it less attention than the company’s new products and almost failed to notice when the deadline for its delivery passed without event.
The programmers revised their implementation schedules and a new delivery date was set some three months ahead in June 1965. Needless to say, that day also passed without event.
I asked the senior programmers once again to draw up revised schedules, which again showed that the software could be delivered within another three months. I desperately wanted to believe it but I just could not. I disregarded the schedules and began to dig more deeply into the project.
The entire Elliott 503 Mark II software project had to be abandoned, and with it, over thirty man-years of programming effort, equivalent to nearly one man’s active working life, and I was responsible, both as designer and as manager, for wasting it.
Mr. Hoare’s classic speech is the source of a few great quotes that have transcended time:
I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult…. No committee will ever do this until it is too late.
A feature which is included before it is fully understood can never be removed later.
At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success.
The price of reliability is the pursuit of the utmost simplicity. It is a price which the
very rich find most hard to pay.
The mistakes which have been made in the last twenty years are being repeated today on an even grander scale. (1980)
Dontcha think that last quote can be restated today as:
The mistakes which have been made in the last fifty years are being repeated today on an even grander scale.
Since man’s ability to cope with complexity is relentlessly being dwarfed by his propensity to create ever greater complexity, the same statement might probably be true 50 years hence, no?
When a failure occurs in a complex, networked, socio-technical system, the probability is high that the root cause is located far away from the failure detection point in time, space, or both. The progression in time goes something like this:
fault ———–> error———-> error—————–>error——>failure discovered!
An unanticipated fault begets an error, which begets another error(s), which begets another error(s), etc, until the failure is manifest via loss of life or money somewhere and sometime downstream in the system. In the case of a software system, the time from fault to catastrophic failure may take milliseconds, but the distance between fault and failure can be in the 100s of thousands of lines of source code sprinkled across multiple machines and networks.
Let’s face it. Envisioning, designing, coding, and testing for end-to-end “system level” error conditions in software systems is unglamorous and tedious (unless you’re using Erlang – which is thoughtfully designed to lessen the pain). It’s usually one of the first things to get jettisoned when the pressure is ratcheted up to meet some arbitrary schedule premised on a baseless, one-time, estimate elicited under duress when the project was kicked-off. Bummer.