Cake! (by alaric)

Sarah made me a nice cake for my birthday. It was quite an involved process:

It's really nice - it tastes of honey! The icing came out runnier than we'd expected and ran straight down the sides and pooled around the base, but that was only a minor issue.

Electricity (by alaric)

Since we had to have the house substantially rewired, due to a combination of flood damage and aging wiring, we had the electrician put in changeover switches on the ring main and the main lighting circuit:

They are the two little rotary switches beneath the consumer unit. Each circuit can choose between the mains feed from the grid, or the corresponding IEC inlet at the bottom of the picture, where we can plug the generator in to feed the house from it.

Also, somebody was amazed at my offhand reference to having military surplus lights from a submarine, so here's the photographic evidence:

They came from Bull Electrical

Tolerance (by alaric)

Recently, there was a bit of a hoo-haa about a blog the Guardian's travel section was planning on running:

(Max, 19, hits the road)[http://blogs.guardian.co.uk/travelog/2008/02/skins_blog.html]

A lot of people responded with reactions varying from amusement to irritation at the Guardian for this project: it was alleged that a naive, over privileged, kid with delusions of coolness was going off on a textbook finding-oneself journey to the East in their gap year, and that he'd landed a job writing it up for the Guardian purely through "daddy's connections". Playing into stereotypes of the rich trust-funded naive types with an over-inflated sense of their own worth, fuelled by parental influence and money giving them the illusion of success. Who later develop into Nathan Barley.

So, Max's blog brought about reactions of anger, both aimed at him and (more so) at the Guardian for apparently allowing nepotism (Max's father is a writer who had done assorted bits of work for the Guardian, so presumably the job was landed through his connections).

But this in turn brought about a second wave of opinion, that people were being cruel in attacking Max, since it wasn't his fault he was young and naive; and his family claimed that he was not going abroad on his parent's money, but that'd he'd saved up his own earnings to do so. The Guardian claimed that Max was playing up to the stereotype with tongue in cheek. In other words, the identification of him with the stereotype was challenged.

Which leads to an interesting point.

Read more »

Flexible data models (by alaric)

Most bits of software have, at heart, a data model for representing whatever it is they process. Be it an SQL database, a bunch of files on disk, a raw disk partition, something purely in memory, or just a file format that is processed sequentially, there is usually some kind of data structure being dealt with.

And when requirements change and the software evolves, that data model often becomes the Achilles' heel, as it turns out to be unable to represent new concepts, and changing it requires rewriting a lot of the application - since, as the "lowest layer", just about everything else depends upon it.

Therefore, I see a challenge in finding ways of designing data models and the software that uses it in the first place so that changing things requires the minimum of effort...

Generalisation (by alaric)

One of the things I instinctively do when designing software, given a client's requirements, is to generalise things as much as possible, in order to make it easier to deal with changing requirements in future, or to avoid having to write special-case code to deal with more unusual situations that they already need handled.

Eg, somebody might say "I want a system to transport email and files between computers in my organisation". So you might think: Ok, I'll start by designing a general packet-switching system to transfer data across an interlinked network of computers, with routing algorithms to work out the best paths, retransmission systems to deal with failures, and so on. Then on top of that I'll build an email system and a file transfer system. That way, most of the difficult stuff is done in a single module that deals with getting data from A to B across an unreliable, changing, network. Email and file transfer are then much simpler modules, with as little duplication of work between them as possible. So it's easy to add more functions to the system in future, and any improvements to the underlying routing engine benefit email, file transfer, and any other application equally.

Standard good software engineering practice, right? Modularise and have an abstract API between layers of a system?

However, sometimes I do this, but am then faced with an uphill struggle, as the client starts wanting changes that break the abstraction layers between the modules...

For example, they might suddenly start saying that they want all the email to go via their fast but expensive transatlantic cable, so it gets their quickly, while spending as little as possible - they pay by the megabyte, but emails are small. Meanwhile, they'd like the file transfers to go via the cheap satellite link, which is slow. But nobody's in a hurry with a large file transfer.

Ok...

But the nice routing module we designed doesn't care what application is using it; it just gets given a bunch of data and told to send it somewhere.

So we have two main classes of choice:

1. Make the routing system, at the point where it has to choose between satellite or transatlantic cable, break the layers a bit by peeking inside the bunch of data it's given to decide if it's part of a file transfer or an email, and decide how to route it based on that. This is quick and easy, but it means that the routing system now needs to know a bit about the applications, so it'll now need updating if extra applications are added or the rules change, which increases maintenance overhead and scope for error.
2. Sit down and have a think about this requirement, and how it might impact future applications (a bit of prediction and guesswork is required here), and design a change to the API to fulfill that need. For example, adding a "type of service" field to every chunk of data given to the routing system, saying whether it needs to get there quickly or cheaply. This creates a more maintainable system in future, but is also more up-front work.

However, it really makes my life hard when people, after requesting a system with so many esoteric variant cases on a complex operation, and the expectation that more variant cases will arrive in future, that it has to be a very modularised system to control the complexity - but where one case is by far the most common - then start requesting changes to the system that totally ignore the fact that there are any exceptions to the common case.

Which is then a real headache to deal with, as you have to figure out how their feature applies to all the other variant cases as well, and try to explain this to them...