scruffian

Between two small “islands” in the Pertuis d’Antioche straits on the west coast of France stands Fort Boyard. It serves as a constant reminder of the futility of human endeavour.

The necessity for a fort in this location was obvious to the French military as far back as 1661. The limited range of cannons meant that English ships could pass unchallenged down the channel, and threaten invasion of the French mainland. By putting a fort in this location the French would cut off this route and secure the French defences.

For a long time the fort was considered to be too expensive:

Your Majesty, it would be easier to seize the moon with your teeth than to attempt such an undertaking in such a place”. – Vauban, Louis XIV’s leading military engineer

However by 1800 Napoleon judged that this was a project worth undertaking and work began in 1801. The work was suspended in 1809, and not resumed until 1837, by King Louis-Philippe. By the time it was completed in 1857, both Napoleon and Louis-Philippe were dead.

Unfortunately, by 1857, technological advances in the range of cannons had increased significantly. When it was finally complete, this fortress, which took 28 years to build, was already obsolete. After a brief spell as a military prison it was abandoned to the sea.

The fortress still stands on the sand bank between Île-d’Aix and the Île d’Oléron, crumbling away with the tides. There are several lessons we can take from this story:

Flexible solutions

The need for fortifications in this area was based on:

•  The short range of cannons
•  The threat of English invasion from the sea

The proposed solution to this problem was obviously costly in both time and money; a whole town was built to support the workers. However this was not the only solution available to the French. There were other options they could have considered:

•  Invest in research into longer range cannons
• Invest in other defence mechanisms which could be effective in this area.

The advantage of these options over the fortress would have been that they would provide value in other locations as well; the fortress was only of value in the one area in which it was built. A search for a more flexible solution may have resulted in improved defences against land based attacks like the French experienced 100 years later, as well as attacks from the sea.

Cut your losses

Even if the French considered that a longer range cannon was not possible when the fortress was begun in 1801, but they time it was completed in 1857 it was a reality. At some point it must have been clear that the advances in cannon ranges were making progress and the fortress would not have brought the value that was originally planned. Why wasn’t the fortress abandoned at this point?

Future proofing

The concept of the fortress was always to make up for a short-coming in cannon ranges. Any project that aims to solve problems caused by a shortfall in another technology is at risk of becoming obsolete when these problems are solved (Twitter API clients anyone?).

Big projects

Fort Boyard took 56 years from start to end; half these were spent building; the other half on hold. Looking at the design of the fortress it is clear that part of the reason for this timescale is that this is a large fortress with sufficient room for a garrison of 250 men. Given that the primary aim of the fortress was to provide a platform to improve artillery cover, the size of the fortress is surprising . Why wasn’t a simple platform built first, for a few cannons and a small shelter as cover for a few men to loaded them (well maybe it was, I’m no historian). A smaller project like this may have been completed in a much shorter timescale and would have improved artillery cover for a period of time when that would have been valuable. Perhaps the project became over-scoped which explains why it wasn’t completed in a timely enough manner to be useful. The same lessons apply when building other things; start small, think about a minimum viable project, ship as soon as possible.

Vision

It could be argued that the real problem demonstrated by Fort Boyard is the lack of a goal oriented vision. Were the French so focussed on this one solution to their problem that they overlooked other opportunities they could be investing in? When building anything it is vital to have a clear vision of what your goal is; in this case the goal should not have been to build a fortress, it should have been to defend against invasion. If the focus was on this goal then the fortress would never have been completed. In the same way, when building anything we need to focus on what the end goal is; not just the next iteration of our current {thing}. Without a goal oriented vision we risk building an improved version of something which is soon to become obsolete.

TL;DR

• Have a goal oriented vision
• Anticipate technological shifts
• Avoid big projects
• Avoid investing in stop-gap solutions
• Cut your losses – don’t be afraid to dump a project and refocus when necessary

Disclaimer: I am not a historian. this is an over-implication of complex historical events. Please do your own research.

We had to leave the beach before I could finish it.

Digging through my server I found a silly little project I made back in 2004: Revolving Doors

Now preserved for posterity thanks to GitHub.

The darkness draws me

Into twisted bramble thorns

Caught by my own trap

I have been noticing this phenomenon for many years. When a particular band becomes popular, often there are other bands who are popular at the same time with similar names. Some examples:

Yazz | Yazoo – both popular in the 80s

U2 | UB40 – both big 80s bands

Steeleye Span | Steely Dan – late 70s

Radiohead | Portishead – both became popular in the mid-nineties

Hot Hot Heat | Hot Chip – rose to fame early 2000s (followed closely by Hot Club de Paris!)

Blur | Pulp | Cast – there are a whole heap of 90s bands with 4 letter names

Kasabian | Klaxons | Kieser Chiefs – all in the mid 00s.

Wheezer | Wilco – formed mid nineties

There are many others who I can’t remember right now. I’ll come back and add them when I remember, but you can add them in the comments.

I have two theories to explain this, both of which probably have some truth to them:

1. There is a fashion to band names. There are a lot of bands from the early 00s who had “the” in their name. This probably explains a lot of the similarities.
2. I also think there might be some cases where one band name is confused for another, so that one band becomes famous on the back of another because people get confused about which ones are being hyped. I have no evidence for this!

Another interesting thing to consider is that bands of similar genres have similar names – most of the bands above share genres.

Can you think of other bands who have similar names? What about similar named songs popular at the same time?

In England there is a word “chav”, which according to Google means:

a young lower-class person typified by brash and loutish behaviour and the wearing of (real or imitation) designer clothes.

Interested in the origin of this word I did some research. The word comes from the Romany words “chavo” and “chavvy”, which mean boy/child. There is also a suggestion that it links to the place name “Chatham” (in Kent). Wikipedia says:

 There is no connection between its current use and its historical use in Romany history

quoting this article as its source. The article, published on the BBC, doesn’t in fact support the claim in Wikipedia, it merely suggests that it has been:

reactivated it in recent times

The OED lists the first reference as a Usenet forum in 1998. I grew up in Kent (not that far from Chatham) in the 90s and I am sure I remember this word being around before 1998. I remember having a conversation with my mother about my indiscriminate use of the word “chav” and the word “pikey“; she was keen to point out the difference: A pikey is a gypsy.

To me (and my brother) the difference between a chav and a pikey wasn’t obvious – they looked the same, they dressed the same, they spoke the same, which is undoubtedly a sign of our ignorance, but perhaps it also explains how this Romany word made a leap from the Romany word for boy, to its modern usage.

Let me try to paint the picture in more detail, which trying to avoid defaming gypsies, who I have a lot of respect for. The modern day “chav” seems to take a lot of things from what is perceived to be gypsy culture; lots of gold jewelry, a big brash attitude, a very strong regional accent, a lack of education and a disregard for the law.

Please note at this point that I am giving my understanding of some of the prejudices that existed in the culture I grew up in, I am not saying that these things are true.

It is really interesting that the word chav was misappropriated from the Romany word for boy, in order to describe a new culture that was in many ways trying to imitate. Firstly, many gypsies are of a Romany origin, so it is likely that they would know this word and use it among themselves. I wonder if the word actually comes from its use as an adjective – “chavvy”, which may have been used to mean “childish”. I can see it taking a leap from this use by gypsies themselves, to others like myself, taking it on but misunderstanding it to mean “gypsyish”. I certainly remember “chavvy” being used as a pejorative term, although by the time it reached me it definitely had connotations of “poor” and “classless”.

Another interesting detail – I met my wife in 1998, and she grew up in the West Midlands. She had never heard of the word before meeting me, which leads me to suspect that this word had its origins in Kent.

What’s the earliest you remember this word? Did you grow up in Kent?

When we moved into our new house, the thing we were most intent on adding was a proper wood burning stove. We had a log burner or fireplace in most of our previous house; I get cold easily, and since warmth is one of Maslow’s fundamental needs I like to be able to provide it.

I believe in burning wood as a sustainable and renewable fuel; it can be carbon neutral and it is very low tech, which makes it a good step towards self-sufficiency.

The house came with this “delightful” gas fire:

I removed this with help from my son, and managed to get a fair price for on ebay. We also removed the block-work around the fire to make the wall flat.

gas fire out

this landed on my toe and broke it

very heavy

child labour

i have no idea why he is in his pjs

not real tools

so happy

supporting rafters

The gas fire out, the next step was to fit the stove and install a twin wall flue.

For the stove we chose a Clearview Solution 500. As we live in a smoke control area, our choice of stove was limited to the list of DEFRA approved stoves but I think we’d have chosen this stove even if we weren’t in a smoke control area.

For our flue installation we worked with Dean at Warm Knights; he did a really great job, as the photos testify!

flu upstairs

the wrong stove

fitting the flue

stove in place

flue in

lighting the fire

The finished result:

The stove outputs 8kW, which is on the large side, but the convection casing and the eco fan means that the heat is distributed nicely around the house. We don’t need to use our central heating at all any more.

The flue has an excellent draw, so it is easy to light a fire, and quickly gets hot. The stove is very easy to control with independent up-draft and down-draft controls. This is a really nice change from previous stoves we have had, which have been hard to light and impossible to control.

tl;dr: get one.

It struck me today that solving problems by writing code is a lot like solving a Rubik’s cube.

When you attempt to solve a Rubik’s cube, doing one side is pretty easy. It can often appear that you are making good progress: it’s already 1/6th complete! As you try to solve another side, you realise that in order to complete the second side, you have messed up the side you have already completed. These unintended consequences are very common when you write code. If you manage to complete 2 sides you feel like you are making significant progress – 1/3rd of the puzzle is now solved, you might think.

As you progress to the next side you become aware of the increasing complexity – how making changes in one place has ‘knock on’ effects in another. With each side you attempt, the difficulty of completing it becomes harder until you realise that you need to take a different approach.

At this point it becomes clear that what appeared to be fast progress at the beginning was deceptive – that, in fact, it wasn’t progress at all, because you were taking the wrong approach. The reality is that, if you had estimated how long it would take to complete the puzzle, an estimate made after one or two sides were complete would be wildly inaccurate – completing one side of the puzzle does not make the puzzle 1/6th complete.

The most common technique for solving a Rubik’s cube is to think of it in rows – starting with the top row, you work down each of the three rows, and finally complete the base. Of course the same principle applies here as with faces approach – the first row is the easiest to complete, and each successive row gets harder.

Solving problems in the right order is critical for success in a Rubik’s cube. If you have a block in the wrong place, but you decide to leave it and come back to it later, once the rest of the puzzle is complete, you will be setting yourself up to fail. Once the rest of the puzzle is complete, going back to fix the piece you skipped will break all of the work you have done since you made the decision to skip a step.

A cube can appear to be 90% solved, but still be a long way from completion, if there are critical issues with certain pieces in the wrong place. Conversely a cube can appear to be a long way from completion, but in fact be only a few steps away, given that you know the steps.

In fact, solving a Rubik’s cube can always be completed quickly: the solution for any combination will only be at most 20 steps. This is because computers don’t make changes that have unintended consequences – they are aware of the side effects of every change they make, so that all of the changes work together:

However humans don’t think like machines. We have to approach the problem in a way which minimises the complexity of each operation – we have to make small changes so we can understand what the implications of each one are – so we don’t mess up the other parts of the system.

By making small incremental changes we can see the implications of every change we make, and slowly chip away at the problem until it is solved.

This is a lot like writing code (especially code that isn’t orthoganal) – where changes made in one place can have unexpected consequences in another. There are two obvious outcomes of this:

1. When working on complex systems, try to make your changes as small as possible, so that you can understand the consequence of every change. This will make it easier to see when things go wrong
2. It’s really hard to estimate how long it will take to solve a problem you have never solved before.

The second point is really important, and worth elucidating on. With the Rubik’s cube, what appeared at first to be quick progress was in fact deceptive. Also, if critical parts of the problem were left until last, the effort to complete the remaining parts would still be large.

So it is when writing (and particularly modifying) code. A programmer that appears to be making good progress can soon find that they will need to make changes which will have implications beyond the scope of the system they are currently working in. The task which on the surface seemed simple suddenly becomes more complex.

Also, if a developer ignores one of the key problems with the system they are creating, hoping to find a solution later, this final issue can end up causing a big delay to a project. This may sound like a stupid mistake that a good developer would avoid, but the fact is that it is often not apparent which these critical pieces are, until a long way into a project.

It could be argued that once you have solved a few Rubik’s cubes you would start to get a sense of how long it would take you – you’d have a system in place and some experience to call on. This is true, but the fact is that the problems that developers tend to face are not ones they have solved before, so, unless they know the code they are working on well, each problem is like a new Rubik’s puzzle.

This is why I dislike estimating how long it will take to make changes to code. Maybe next time someone asks me I will give them a Rubik’s cube to solve.