A bit of archaeology - The value of having no choice

I've been retired now for more than 18 months. One of the things on my 'to do when I retire' list was to sort out my Blogger account. Like most of the things on that list, I haven't done it. But today, I clicked the Blogger link in the apps menu on Gmail, and here I am. An unfinished draft from 2014 caught my eye.

 

Today is Sunday, which means it is cycling day. For the past 5 or 6 years, I've ridden my mountain bike at 08:00 every Sunday I can. My partner in crime is a guy called Dave, and over the years our riding has kind of evened out. When we started riding together, Dave was faster up the hills and I was quicker on technical stuff or downhills, but these days there's much less difference between us. Our bikes are pretty standard mid to high-end bikes, with suspension at both ends and 30-odd gears. But now something's changed. Dave has acquired a singlespeed bike. In fact it's not only singlespeed, it's made of steel and has no suspension at all. Back to basics, you might say.

I vaguely remember that back then I intended to make some work-related point about how having no choice was actually quite liberating. That it wasn't necessarily a good idea to remove constraints. That necessity was the mother of invention. I still think that there would be scope for doing something like that, but these days I'm not really so bothered. I've got nothing to sell any more. I'm retired.

These days I too have a singlespeed. Made of steel (853 steel, if you're bothered about that sort of thing). With no suspension. On many days, in the winter usually, it's my favourite bike. There's nothing to it, apart from its essential bike nature. It has a purity about it. Some might say it makes things needlessly difficult, but I'd counter by saying that it makes things utterly simple. Do you have the strength in your body and the quality to your technique to get up that climb? Through that swamp? Over that step? Riding my singlespeed has made me a better rider in all the other disciplines I attempt, even road. I'm stronger, my balance is better, I can pick a better line.

Eight years later, I agree with my 2014 self that there can be benefits to simplifying your approach, to reducing your choices, to stripping away the things that might be nice but maybe you don't really need.

And just look at it. Is it not a thing of beauty? 

Going for a walk - Eldest Child has an idea

August. Holiday time. Despite the fact that our children are all in their 20s and don't live with us any more, 2017 was the first year that we hadn't all been on holiday together. This year, 2018, is our 30th wedding anniversary, so you might have thought that we would once again head off without the offspring, perhaps to somewhere romantic - Bali, Fiji, Prague or somewhere else sold to us as the perfect place to celebrate togetherness. But no. The eldest child had a suggestion. "Let's all go for a walk", she said, "to celebrate your anniversary".
We had holidayed in the Alps before, staying in Samoens, a small but growing village in Haute-Savoie. We had done a lot of hiking, sometimes coming across red and white waymarkers which we learned indicated the GR5, a long distance path which runs through Samoens on its way from Hoek van Holland to Nice. We saw the mountain refuges marked on the map, where hikers on multi-day routes could get basic accommodation and food, and we had idly speculated what it would be like to take part in such a foolish activity.
Eldest child's idea was to walk from Lac Leman to Samoens on the GR5, staying in the mountain refuges along the way. Bizarrely, we all agreed that this was a great idea. I offered to arrange transport to the start and a place to stay in Samoens, and Eldest Child took on route planning and refuge booking. We complicated things a bit by deciding to avoid aeroplanes, so the journey to Evian involved Chiltern Railways, a London Bus (the 205, if you're interested), Eurostar, RER, TGV Lyria, Lausanne Metro, and the CGN Navibus. This would get us to Evian around 9 or 10pm, so we'd need a hotel for the night there, and getting to London in time for the Eurostar looked a bit marginal, so I dug into my hotel points to get us somewhere to sleep near St Pancras. Then, a more detailed examination of the route revealed that the first day was impossibly hard for ordinary mortals, so we added a local bus from Evian to our actual start in Bernex. It was starting to feel like an adventure before we'd taken a single step.

[June/July 2022 - I never finished this series. But I've just returned to it, and more episodes will follow soon. Did we make it? Stay tuned....]

Respect

There is growing appreciation of the fact that agile approaches are in fact just applied common sense. Recently I have also found it striking how many agile practices (and un-agile anti-practices) can be justified by the concept of respect. Some examples:
 
It is disrespectful to developers to impose arbitrary estimates upon them
It is disrespectful to customers to ask them to sign off requirements which they can not possibly understand
It is disrespectful to customers and developers to pretend that a paper-based design is anything other than speculation
It is disrespectful to everyone involved to suggest that an estimate for solving a novel problem in a novel way is anything more than a guess...
It is disrespectful to everyone involved to ask them to spend time writing, reviewing and signing off a document that will never be referred to again
It is disrespectful to team members to throw them into a situation without allowing them proper preparation and training
It is disrespectful to customers to sell them a team to whom you have done the above
It is disrespectful to blame or reward individuals when the system is responsible for 95% of their performance

...and so on.

Given Agile's roots in the Toyota production System, with its twin pillars of Respect For People and Continuous Improvement, this shouldn't be surprising, but I can't help feeling that more awareness of this aspect would help reduce the amount of Cargo Cult Agile that we are seeing.

The chicken fence and BDUF

This is my first blog post in over a year - I've been Twittering, Yamming and Facebooking instead. When I logged in I found a draft post from 2008 about our Canada road trip just lying around like a half-eaten pizza, but decided not to finish it - usually wise with pizza of that age too.

So, I've just spent two days in the garden, building an enclosure for Paris, Amy and Martha. We had been using some of this netting from Omlet, but I was fed up with having to climb over it, and it just looks a bit scruffy.

The requirements were simple: it had to be a permanent fence, not too expensive; with a gate in it so that we could get in to retrieve eggs, clean out the Eglu and so on. How hard could it be? I decided on a post and rail fence, with 3" posts and 3" half-round rails with chicken wire fixed on to it to retain the chickens (radical use for chicken wire!). After a little difficulty getting hold of the wood (eventually found at Curtiss Timber who were most helpful) I started to build the fence. To be on the safe side, I designed it to be nearly 20% taller than the netting had been.

It too a little longer than I had expected - a combination of incompetence, lack of some tools and some contraints on the working area - like some of it was in the middle of a rose bush - but eventually it was finished. I proudly displayed it, working door with latch and all, to my family and started to put the tools away. Out of the corner of my eye I saw first Martha, and then Amy fly straight up and perch on my lovely new fence.

After two day work the new fence met all the requirements, except for the primary one of actually keeping the chickens where we wanted them and thereby preventing them from digging up all the bulbs in the garden. My office worker's hands were raw, I was tired and I felt like I'd been beaten up. And the bloody fence didn't work!

What tortuous lesson am I going to draw from this sorry tale? What happened was that the hens saw the new fence as an inviting perch in a way that the old netting never was. Despite being higher than the netting, the new fence was therefore worse at its main function. I've seen this happen so often in business, where the shiny new system fails to deliver the expected benefits. It underlines the importance of taking a small step at a time and validating as you go that you are getting the value you expected. Big-bang deployments, especially those developed using a a waterfall process like my fence, almost never deliver the desired result.

Reality

There's no real point to this post. Perhaps that's the point.

I was sitting in a fake Irish bar, in a concrete hotel in Bloomsbury. The clientele was...interesting, and probably didn't support the image the hotel wants to promote. They didn't have any real beer so I was drinking a Stella Artois, served in one of those ridiculous goblets. I was reading William Gibson's 'Pattern Recognition' and appropriately the jukebox was playing The Who - first 'Won't Get Fooled Again', then 'I Can't Explain'. I found it increasingly difficult to feel where the book ended and reality began.

That's all.

Why Software Sucks

Earlier this year I enjoyed reading David Platt's 'Why Software Sucks', in which he discusses why software is regarded so poorly by so many people. It was entertaining, well written and contained a fair amount of wisdom. I'd certainly recommend it to anyone considering writing any software with a user interface.

I was reminded of the book today, when this masterpiece popped up on my screen (Click on it to see it full size):


I've read it several times now and I'm still not sure what it means. I'm pretty certain that I'm not likely to trust any site that asks questions like that. I'm also sure that I don't really trust the test and QA processes of any organisation that lets software like that out of the door.

To make matters worse, there is no way to tell this baffling and irritating dialog to go away. Choose 'No' and it will reappear every time you go back to the page that launched it.

It is always nice to have your prejudices reinforced (I'm not a massive Microsoft fan), and I did really enjoy the slightly theatrical rant I was able to have as a result. But my employer forces me to use this software, and I think I'd really rather they didn't, particularly when there are a number of open-source alternatives that treat their users with a little more respect.

P.S. I initially thought that it was another display of suckiness that it wasn't possible to tell Blogger to upload the picture of the dialog full size - but to do so would ruin the design of the page, so it's probably OK.

Quality Software Development - Science or Art?

In a thoughtful and well reasoned post on Sys-Con, Dirk Morris draws on the arguments in Zen and The Art of Motorcycle Maintenance to put forward the view that software development is both Science and Art. Rather more interestingly he suggests that Open Source tends more towards the science, and proprietary software tends more towards the art, citing Apple's OS X as the prime example - open source engineering at the core, with proprietary eye candy on top.

Blogged with the Flock Browser

Mad Old Men

I took my son J (13) to his first real gig on Sunday. We went to see the Blockheads at the Stables in Milton Keynes. J isn't a big Blockheads fan (although he might be now), but he's a pretty good musician and singer, so I thought he'd enjoy it. After 3 songs, he turned to me a said with a big grin "they're just a bunch of mad old men". I guess they are, but after 30 years of playing together they are an unbelievably good band; with some absolutely classic old material as well as some surprisingly good new stuff it all adds up to a great night out.
I've seen them three times now in the last year or so, twice at Cox's Yard in Stratford upon Avon and this time at the Stables. The Stables is a nice venue, set up by John Dankworth and Cleo Laine, but Cox's suits the Blockheads better - something I think Johnny Turnbull had in mind when he asked the audience to give themselves a round of applause for staying sat down all night. On the other hand, if we'd been at Cox's J would have difficulty seeing anything - neither of us are particularly tall.
Anyway, overall we really enjoyed it, the nearly two hours of their set passed very quickly (certainly much more quickly than the 40 minutes of the support act, which was absolute torture). If you get the chance to go and see them, don't miss out!

Blogged with the Flock Browser

Specialized Defroster Shoes

Cold feet are not something I have ever really suffered from - at least, not unless they were soaking wet. So I've been cycling offroad year-round in a pair of lightweight summer cycling shoes for a quite some time. The uppers are largely mesh, so they do tend to fill with water/mud fairly frequently in winter riding. Usually, on the wetsuit principle, the water/mud warms up and after the initial unpleasantness my feet are OK again, but when it is really cold this doesn't always work, and does tend to provoke some protest from the kind person who washes my socks. So when I found myself in the Specialized Concept Store and saw a pair of Defrosters I thought I'd give them a try.

I bought a pair of size 44 rather than my usual 43, and I despite going up a size I can't fit my feet in with anything but my thinnest socks on as they are too narrow. Despite that , my feet have been extremely warm on all of my recent rides. Of course, as soon as I bought them the rains stopped and the trails got dryer than I've ever seen them at this time of year, but today in the rain, mud and severe winds they got a proper test and passed with flying colours. It was very comforting to have such warm, dry feet in such inclement conditions.

These are my third pair of Specialized shoes, but the first for a few years and the first that I have found to be too narrow. Perhaps they now use a different last?

Apart from the width issue, the only other issue I have with them is that clearance for Crank Brothers pedals is pretty marginal - you need to fit the shims provided with the cleats, and even then clipping in is not as easy as it should be.

There really isn't much choice in the winter mtb shoe market, and finding a shop with anything in stock seems to be a major challenge. In fact, I think this was the first time I had found any winter show in stock in my size, so I didn't really get much choice. So overall, I guess I'd give them a 6 out of 10.

Can outsourcing save money?

The AA has decided to bring its datacentre operation back in house to save money. This isn't very surprising if you stop to think about the basic economics, but it does seem quite brave of them to admit that the outsource decision was flawed. It has always seemed unlikely to me that you could save money by outsourcing infrastructure in this way, unless your in house setup was totally incompetent (in which case fixing it would seem to be the better option). Unlike in the early days of facilities management, there is no option to save money by consolidation workload onto fewer mainframes, so the cost model for the outsourcer is likely to be the same as yours - add in a profit margin and account management overheads and you are paying more. Even worse is the degree to which your ability to support your business is compromised. I have worked on accounts with some large infrastructure outsourcers over the past year and the striking thing is how long it now takes to make any changes - and how much it costs.

The other interesting thing about this news item was the decision to accept a lower level of availability - 99.5% instead of the 99.9% or more that is usually asked for. Like Google's practice of running their datacentres rather hotter than is considered normal, it suggests that there are a few bits of conventional wisdom that could do with revisiting.  All it takes is a clear look at the numbers

Is it China? Or is it you?

Will Hutton, in the Observer, explains "why the Himalayas might not look like this for much longer". He points out that the Chinese are playing an enthusiastic role in the destruction of the Earth's ecosystem, and seems to assign a large part of the blame to the lack of democratic accountability in China. But we should look closer to home for those responsible for this destruction of the environment. Have you bought a computer recently? Have you benefited from the deflation in consumer goods prices? Ever wondered how it is possible to make all this stuff so cheaply? It isn't just that the workers in China don't get paid very much; or that they don't get sick pay, or a pension. It is also that there are no expensive restrictions on the disposal of toxic waste, or the emission of toxic pollutants or greenhouse gases. When we 'outsource' this manufacturing, we also outsource the damage that it does to the environment. The companies that do this do it knowingly but in general the consumers who collude with them just close their eyes to the reality - out of sight, out of mind. But it won't go away; there is only one planet, and we are all living on it. We must consume less, no matter how tempting those low prices might be.

Good job HP!

Not quite such a good job Citylink.

HP have been doing pretty well in the PC market recently. Looking around my house there are 5 computers, 3 belonging to us and two belonging to my employer - they are all HPs. I can't answer for my employer, but in the case of our machines I didn't go looking for an HP, it just seemed to be that the best deal I could find was an HP. Now it turns out that the after-sales service is just as good.

My son has an HP laptop, abut 9 months old, which recently started forecasting the demise of its hard disk. So we called HP and they said they'd pick it up on Wednesday. On Monday we got home from work to find a card from Citylink saying they'd tried to deliver something, and if we wrote on the card where we wanted it left they'd have another go on Tuesday. So we wrote some instructions and left the card for the Citylink driver, and when we got back from work we found a card saying that he was actually trying to collect the laptop. On Wednesday, as arranged, we were in to hand him the laptop - he had a specially designed transit case for it with lots of foam padding. On Friday he reappeared, with the transit case again - I wondered if a routing error had just returned the broken machine to us. But no, the computer had a new hard drive and a reflashed BIOS and seems to be fixed - all under warranty. I think this is pretty good service - if Citylink had managed to turn up on the right day I'd say it was perfect service.

Target-driven management

Once again, I am inspired by Simon Caulkin of the Observer. The context of his rant is the health service, but the lessons are far more broadly applicable. It's long been the case that you could trace the ills of most organisations back to the performance-related pay schemes of its managers, but the problem has got worse (at least in the UK) since our government's enthusiasm for 'proving' what a good job it is doing by 'meeting' targets.

In our business, I have seen many instances of damaging targets. I once worked in an organisation where it was decreed that we all should be given a target of contributing a certain number of pieces of 'intellectual capital' to the knowledge bases every year. Unsurprisingly the knowledge bases soon filled up with utter cr*p, but hey, we met the targets so the bonuses were paid. To deal with the quality issue, someone came up with a cunning plan - all contributions had to be rated by one's peers, and only those which had a high enough score would count. So a system of 'you rate mine and I'll rate yours' arose, the knowledge bases continued to fill with rubbish - and we continued to get our bonuses, effectively being paid for wasting the companies' money and time. Other instances are paying people a bonus based on bugs fixed, which leads to the deliberate introduction of easy-to-fix bugs and a nice little earner, or rating people by lines of code written, which leads to an orgy of cut-and-pasting.

Caulkin points out

if enough pressure is applied, people will meet targets - even if they destroy the organisation in doing so. As quality guru W Edwards Deming put it: 'What do "targets" accomplish? Nothing. Wrong: their accomplishment is negative.'

At a high enough level of abstraction, targets are fairly benign. It is when they are chosen just because they are measurable the damage really starts. They also usually encourage short term thinking, erode trust and therefore the feeling of personal responsibility for outcomes. Targets are set top-down, in advance - the management equivalent of waterfall development. Human nature being what it is, targets trump thinking - and if we've learned one thing about software development in the last 40 years it is that thinking generally helps the process.

The agile movement tends to avoid numerical targets in favour of more woolly but also more useful aims such as delivering value to your customer. My experience is that when we trust people to do a good job, and remove the obstacles to them doing so, the results are invariably superior than when trying to coerce that behaviour by the use of targets.

Open Source Lessons

Writing in The Observer (a UK Sunday Newspaper) Simon Caulkin suggested that open source development represented a new way of working with wider applicability than software development. Commenting on a new book by management guru Gary Hamel, he points out that existing top-down management structures are both expensive and inefficient, and then continues:

But internet-enabled networks offer a credible third way, Hamel believes. The prime exemplar is Linux, the open-source operating system developed by a self-selecting band of volunteers linked only by the web and their motivation to contribute. There are now 150,000 open-source projects using the freely given energy and initiative of 1.6 million people, according to estimates. While many of these are not-for-profit enterprises, the lessons that they embody have wide application...

Leaving aside that the primary purpose of management books is to sell management books, there is clearly a grain of truth here. The self-organising teams of the agile movement, and the open source community have shown that it is possible to manage complex endeavours without a huge management overhead, and often in a way that is far more enjoyable for the workers than conventionally managed efforts. The main objection that I can see is that the members of successful agile development teams and open-source projects are largely self-selected and drawn from a very thin layer at the top of the development gene pool. Translating their experience to the wider working world will be challenging; and of course, getting management to support it will be like getting turkeys to vote for Christmas :-)

Why did he jump?

That's the big question he doesn't answer, but apart from that this interview in the Microsoft Architecture Journal with Don Ferguson, ex-Chief Architect for IBM Software Group and now a Technical Fellow at Microsoft, makes interesting reading. Some selected nuggets of wisdom:

You should never underestimate the importance of a social network. You don't know what you don't know. You don't know what someone may say to you that can push the reset button in your brain and make you think differently.

...communication skills matter. They really do. It's really important to understand how to write well and how to present well.

Secondly, many people who work in technology suffer from the "endgame fallacy." We are all pretty bright. We see a lot of customers. We see what they are doing and then plot a trajectory for where they will be in a few years. Once you do this, however, it's too tempting to build what they will need in five years, and not what they need next or are ready for.

Still wish he'd explained what was behind his move from the top technical job in IBM software to Microsoft though.