Obsolescence – building to last

This is part two of a series on obsolescence, value, cost and things like that. It’s mostly about computer hardware and software, but drawing on other things too.

1. Cars and computers
2. Building to last

Boots and white goods

The Discworld books by Terry Pratchett are full of wisdom.  (They also have interesting characters, humour, and an authentic-seeming world.)  One bit of wisdom is Sam Vimes economics.  Sam Vimes is a police officer, who starts as a Bobby on the beat and ends up as a Duke.  He has seen life from its grubbiest and most desperate to its most refined and coddled.

He realises that it’s cheaper to be rich than to be poor, through the lens of boots.  If you’re poor, the only boots you can afford are cheap ones.  These are cheap because they’re poor quality, so they wear out quickly.  You then need to buy new boots, which are also cheap and poor quality, and the cycle continues.

If you’re rich, you can afford an expensive pair of good quality boots.  These last for ages because of their quality.  In fact, they last for so long that a poor person has had to buy many pairs of poor-quality boots in that time.  The total amount of money the poor person spends on boots is more than the rich person spends.  So, it’s cheaper to be rich than to be poor.

I haven’t learned this through boots, but I have through white goods. A while ago we needed a washing machine and a dishwasher.  We had some money saved up at the time, and so we bought them from Miele.  These were more expensive than some alternatives – not because they had more bells and whistles, but because of their quality.

They’ve taken a lot of use since then, and getting one repaired was expensive, but averaging out the total cost over their lifetime meant we spent less on washing machines and dishwashers than if we’d bought cheaper ones to begin with.  However, like with Sam Vimes’ boots, not everyone is in the position to save money like this, because to save money you need to have some in the first place.

Summer jobs

This is supposedly a technology-related blog, so here’s the technology bit.  Unlike real world things, software usually doesn’t wear out over time, but you still need to think about cost and value, and how these vary over time.  I learned to think about this over twenty five years ago, when I had summer jobs at the same company for two years in a row.

In the first summer there were two of us students working at the company.  The other student was given a project close to the company’s core product and got stuck in doing impressive-sounding stuff, without doing much designing or planning.

I was given the task of writing a program to change the layout of the company’s manuals.  I had to teach myself C from the standard K+R book, understand the printer control language used to encode the manual and then write my program to shuffle the pages around.  It was a nice project, even though it wasn’t glamorous, and I finished it before I had to leave.

I came back the next summer, but the other student didn’t.  I was mostly doing technical support, and had nothing to do with manuals etc.  I asked the permanent staff what had happened since the other student and I left the first time.  The other student’s code had still not been debugged to the point of being useful.  The requirements for the manual-processing code had changed, but because the code had a decent structure and things were named well, they could understand it and modify it easily to meet the new requirements.

That really drove home to me the concepts of false economies and building to last, as they apply to my profession.

Throwing the baby out with the bath water

The approach to writing software that was common when I started my career was waterfall, which included Big Design Up Front.  The idea was that at the start of the project you would think hard, produce a design that eliminated risk and answered all the important questions, and only then would you start coding.

The flaws in this approach have long since been known, and solutions such as agile and lean proposed as better ways of working.  These favour working software over documentation etc, and a more subtle approach to risk, where you get meaningful feedback as quickly as possible.  This can take the form of a working version of a subset of the requirements, so the customer can see it and possibly change their mind or realise that they’d expressed themselves poorly.

However, there’s a temptation to throw the baby out with the bathwater.  Agile isn’t about no design – either thinking or documents – it’s about the right amount of design done at the right time.  Or another way of thinking about it is – you’re trying to maximise the value that your software produces while minimising the cost and risk involved in producing it.  Design documents are an overhead – a cost – in that they aren’t in the user’s hands helping them to do something.  But if they help the software get to where it needs to be more quickly and with fewer bugs, then it’s daft not to create them (assuming they don’t take ages to write).

Also, it’s worth thinking about when the costs occur and when their benefits (in terms of increased value) occur.  If a piece of software lives for years, or even decades, the cost of design and similar overheads is spread over a long time.  It’s easy to see the cost – because it’s usually earlier in the process, in a concentrated lump.  Even though it’s harder to see the benefit, it doesn’t mean it’s not there.

To think about it in terms of Sam Vimes’ boots again, it’s better for you today if the boots you bought last year were good quality expensive ones rather than cheap ones that have already worn out.  But building to last does cost more up front, even if it’s cheaper in the long run.  If you’re not able to afford that then you have few options, but I wonder sometimes how many deadlines (that encourage short term commercial thinking) really should be allowed to win over longer-term commercial thinking.

Understandability and repair

I think that a key part to software value is repair.  This is not just fixing things that have broken (bugs) but anywhere where the behaviour doesn’t meet requirements, i.e. including new features as requirements change.

Understandability is a key factor in being able to repair.  Another factor is the repair leading you to change or replace just the bit you need to, at acceptable cost and risk, rather than having to remove lots of surrounding stuff, or being worried that you’re breaking something else in the process.

Writing software is a creative process.  Our pride tempts us to think that we’ve written the next masterpiece, which will live for all time like a platonic solid of the software world.  However, this is rarely true.  Software is like a living organism in that it usually needs to change over its existence, to respond to changes in its environment (e.g. the requirements that users have of it).

An appropriate amount of helpful design, decent structure and names, and tests that give good feedback all help with this.  They create an environment where repair is more feasible, cheaper and less risky.  These mean the software’s value can be extended into the future.

I’m aware that the pendulum can swing too far the other way, and that’s wrong too.  You could stray into gold plating – adding things or improving quality beyond the point where the extra value justifies the extra cost.  You can also stray into boiling the ocean – attempting to do something enormous in one go, rather than breaking the work into chunks, and delivering the chunks as they’re ready.  This includes Minimum Viable Product, but also things like Jez Humble’s excellent talk on always thinking of value / cost (where value is measured in terms of cost of delaying the work being ready).