I’ve not lost data due to lack of backups in five odd years, since I constructed a vastly improved backup infrastructure/version control system. As such, I’m refusing to confirm this latest idiocy.

On the plus side, these hypothetical lost images are not of great import.

I don’t buy the highly expensive bottles (I’n not that rich, nor that trained), but when other people have been kind enough (or when I’ve drunk too many cheaper glasses and am in a suitable bar), I have indulged and come to the same conclusions. But I’ll add a corollary - on average, very cheap wines can be hit and mostly miss, especially in the realm of red. The value curve has it’s peak at about, for me, £10 to £15 a bottle.

Now, I certainly don’t think you can’t get decent wines for less (I have, do, and continue to), nor that every “mid price” bottle is better (some are dross). Just that if you do your research, that price point has the widest selection of bottles that taste well above their price range, without seeming ostentatious.

Note that I’m talking about wines bought from a store, not a restaurant. Wine by the bottle with a meal starts at about that range (and normally they’d have paid about a tenth of that for it).

Overall, I’m very happy (but then, I’ve been a Mac laptop user for years). The only problem is the TN panel screen, which has an annoying top to bottom gradient (some colours get very desaturated as you move down the screen). It’s not ideal, and less than I’d expect from Apple. However everything else is perfect, and as I’m no graphic designer, I can afford to live with it.

My first tiplet (which is no doubt very obvious to most people, and maybe even in the help files) is that you can save Automator workflows as application bundles. It’s significantly easier to achieve some small tasks (which don’t have control structures) with this mechanism - I currently use it to read me the RSS news headlines when the machine alarm goes off. Yes, this could be achieved with more traditional programming methods, but occasionally, graphical workflow tools are useful.

Some types of errors can be argued to fall into multiple groups - this is no bad thing. The idea, eventually, is to speak of how effective certain techniques are at preventing certain types of error.

Errors of ignorance
When you don’t know what you’re doing

A remarkable amount of bugs just boil down to raw incompetence. Harsh words, but in reality, we’ve all been there. Using languages and frameworks before we’ve actually performed some experiments, being thrown into fixing a problem in a system we’ve never seen before, being forced to render comment on a project before we’ve even seen a spec - all old stories for even the most talented developers. Errors of ignorance capture the problems you introduce in this state - using the wrong constructs, not knowing what frameworks actually do, and generalised language idiom failures.

Errors of expectation
When the outside world intrudes.

Most of the time, we’re dealing in some form with input in our programs. If we expect input in a certain format, and receive it in another, this is our fault - we need to be more robust. We might also think we’ll get input in a given format, but it’s subtly different.

We can also have expectations on what other people will provide for us, or the side effects they will have on the world. Any problems induced by our expectations differing from reality, I’m currently calling “Errors of expectation”.

Errors of omission
When you forget to handle something

Often, we know what we’re doing, we intend to do it, and then just forget - perhaps to handle an edge case, perhaps to release a resource. Our natural forgetfulness leads us into “Errors of omission”.

NB: This is currently my least favorite category, which I hope to kill off, but some bugs just fall into this group very naturally.

Errors of intention
When you just got it wrong.

These are what most people would call bugs - when the we, the programmer or designer, just get it wrong. Perhaps we thought the algorithm worked when it didn’t, perhaps our mathematics is just wrong, perhaps our expectations are mutually inconsistent. The code is doing exactly what we wanted - it is, in it’s way, flawless work. It just doesn’t do the right thing because, even having missed all the above classes of errors, we still didn’t know what the right thing was - we’ve committed an “Error of intention”.

This is my first attempt at a concise set of names to concepts I’ve been dealing with for years - it will be interesting to see how they evolve as I try and put it to use.

By idiomatic failures, I’m referring to common mistakes and patterns that cause errors. Suitable examples from other languages would be

• In C, failing to account for the null string terminator
• Buffer overruns, in C and C++
• Off by one errors in pretty much every language
• With C++, delete’ing a new[]’d resource
• In PHP and many other scripting languages, failing to account for the weakly typed comparisons (so you forget that 0, null and the empty string are treated as semantically the same under comparison, but are distinct in your program logic).

These are the building blocks of certain types of program failure –often, when debugging, one of these type of error is the cause.

Of course, I’ve run into these many times myself, but that doesn’t really say much about the commonality of the problem; I may be a particularly poor programmer. So, I’ve been spelunking around bug databases for long running open source projects (i.e. the Javascript libraries behind Ruby on Rails); this is proving somewhat fruitful, but it’s a statistically invalid sample. As mentioned, the bug databases only tend to get populated by bugs in release versions, and then only the bugs that people have bothered to report. If a developer finds a bug whilst he’s developing, these are often not added – even if it took days to track down. Moreover, if they find a bug in a release version themselves, they often quietly fix it. Bugs that only occur rarely and are not repeatable are added almost never.

In a way, this is quite good – the failures I’m seeing are the ones that escaped testing, escaped the eyes of the developers, yet blew up in a users face. These are the hard to see bugs – the most annoying of the species. On the other side, this is quite bad – I miss a huge subset of bugs that fall into my class of interest.

Of course, these types of problems could be considered language defects – stupid mis-features that bite people again and again specifically because they are so artificial. After I have a relatively complete map of these failures, I’m going to move onto logical failures and failures of design that are common within Javascript/DOM – i.e. conceptual black holes that people are repeatedly sucked into, the actual failures of programmers.

Comments are now being checked by the built-in Wordpress Akismet spam checking engine. If anyone has any trouble, just drop me a line.

A good education in what sort of posts don’t work, and preparation for writing again!

Insanely busy, but not dead. Here’s a photo from last summer. When I can spare the editing time, I’ll distill some of my academic writing into posts here.