I'm with you on much of that, but just wanted to pick up on this point:

It's not the original purchase cost I'm so worried about in the case of dubious copy protection mechanisms, as I suspect you would have ways to get that back anyway if, say, the software wouldn't activate. What interests me in light of this case is the consequences if installing business software on a work machine rendered the PC unusable because the accompanying malware corrupted Windows, damaged the data in the boot sector, etc.

I'm particularly aware of this because not so long ago I switched to freelance work, which means that working time very much is money to me now. The thing that makes me wary of so much modern business software isn't the cost of buying it, which is a business expense I would incur anyway, it's the unknown losses due to downtime if all this activation and DRM technology somehow takes out an essential PC that I need to work on a contract.

My perception from reading various reports on the Web is that most of the time, the big companies do get it right, but if you're the unlucky one whose system is a bit unusual or whose product key some pirate clones, then there's a good chance you'll be hung out to dry. I would feel much better about investing in high-end software if I knew that I would have grounds for compensation if my business was interrupted because the attached malware went wrong under such circumstances.

I had a hybrid version: an automated car wash at a petrol station did serious damage to my car after it collided with it.

The immediate reaction from the staff on site was to deny everything, point at some weasel words on a sign full of disclaimers, and claim that my car wasn't suitable for their machine (even though they could see it when they sold me the token to put in the machine, and it had been through the same machine without incident on several previous occasions).

However, when it reached their central "customer care" people at head office, they immediately arranged to pay out a substantial sum of money to cover the cost of repairs on a reasonable basis (asked me to provide two quotes from reputable local repair shops).

I later discovered that there had previously been at least one similar case that had gone to court, where the car wash operators pretty much got torn a new one. I imagine the "customer care" people were aware of this, or at least their legal team was.

On the contrary, it seems this ruling says precisely that software must be good enough. Unless there's something in the actual ruling that is completely missing from TFA, this doesn't require all sold software to be perfect or bug-free, just that it be fit for purpose and of merchantable quality.

That probably means that the more you pay for software and the more the advertising promises, the better the quality and functionality would need to be. A cute graphics demo that cost £1 on an app store for your mobile phone would not be expected to do the same things and with the same reliability as medical device control software you sold to a hospital at £100,000 per unit.

I am not a lawyer, but I fail to see why. From the Sale of Goods Act 1979, 2(1):

I doubt £0 would constitute "consideration" in this context.

As far as I can see, the most significant consequences of this ruling are that:

• software can be covered by consumer protection legislation;
• those selling software cannot escape responsibility for the related obligations just by putting small print in a contract of adhesion; and
• liability can exceed the original cost of the software where the damages are greater.

This is particularly interesting because if EULAs do have any legal standing at all here, then they are probably a contract of adhesion based on technicalities about copyright.

I imagine some lawyers are running around looking nervous at quite a few big software companies this morning. All those DRM systems, for example, just became a bit of a liability: if I install a game and it simply doesn't work, then all those arguments about not returning opened products for a refund just became untenable. (Take note, Ubisoft and games shops.) And if you play silly wotsits on someone's computer to try to install your software's copy protection system and you get it wrong and damage their system, $DEITY help you, because it looks like the courts aren't going to. (Take note Sony, Adobe, et al.)

Of course, we'd have to see the complete context before reading too much into this case, because it sounds like the sale was made following significant contact between the parties and specific claims by the sellers, which might or might not still be the case with typical off-the-shelf or preinstalled software.

Not necessarily: the libraries I used to work on used floating point values for the APIs. Typically, there would also be explicit resolution/tolerance values provided, which would be chosen according to the scale of the model.

Well, OK, I’m moving the goalposts. But discussing something that strictly speaking no-one can do isn’t particularly interesting, while there is an interesting underlying issue of whether it is cost-effective to write relatively high quality software, or whether we are doomed by economics to the predominantly mediocre mass market software we use today.

The problem with that argument is that there is little evidence that it is actually true.

Let’s assume that by “perfect” what we really mean is “much better than most software today”, since no-one has yet worked out how to write literally perfect software. In that case, the difference in cost (by the time you take into account the full lifetime, including maintenance costs) seems to be rather small: it's not that great even during initial development, and the lower maintenance costs make it rather efficient to put more up-front effort into making less buggy code.

For what it’s worth, that’s not really the kind of target I was gunning for. If you’re going to program in Perl, then of course you need a reasonable level of Perl proficiency to understand the code, and your example is hardly esoteric. I would imagine that it is also comfortably within the ability of a typical Perl programmer to comprehend after a little reading, if they haven’t encountered functional style before.

OK, but if your code is ugly, will you be sure that it is implementing the right solution, and that you can keep it that way as it evolves?

That’s a fair point.

Curiously, though, such code often becomes simpler from some perspective. For example, extreme optimisation sometimes comes down to things like efficient use of pipelines and caches. Achieving these goals might lead to more straight-line code or to a “flatter” memory layout with related data stored together.

Such optimised code might not be the way you would “naturally” write the algorithm, but a quick explanatory comment goes a long way, and surely anyone working on such performance-sensitive code would be familiar with these principles even if they hadn’t seen a particular case before.

Moreover, this all tends to happen at a very low level. I’ve rarely seen a case where the performance-driven hackery couldn’t still be wrapped up in a fairly tight module and present a normal interface to the rest of the code.

Sure, of course. I was oversimplifying, perhaps a little too much.

That said, I do think it’s a reasonable goal that code written for a certain project should be accessible with only minimal support to anyone from that project who is likely to read it. That is, while it may sometimes be necessary to deviate from this rule for practical reasons, such deviations should be deliberate and for a specific purpose, and suitable precautions should be taken to make sure any reduction in clarity does not become a liability.

Well, please notice that this isn’t what I wrote. I talked about a situation where you had lost both the original developers and the knowledge they had. Documentation is one way to pass on that knowledge, but sometimes one of the least effective. If you can still recover it in other ways — for example, if the code is well-written and self-documenting — then you might still be in the maintenance stage of the project rather than servicing.

Also, remember we’re only talking about a relatively small code base here. There probably isn’t a huge gap between making tactical changes and effectively rewriting the part of the system concerned anyway.

I agree that a rewrite is very expensive, but there is an implicit assumption in your statement that it is possible to achieve a sufficient level of mastery to make the required modification effectively instead. Maybe you feel that for a 30–40 KLOC program, such a level is always attainable, and perhaps that is correct. But in general, once you’ve lost too much, it becomes very difficult to continue performing a full range of maintenance on the project.

I always thought clever code was code that everyone could understand, not code that no-one could understand.

It’s like Blaise Pascal’s apology for writing a long letter because he didn’t have the time to make it shorter: it’s often easier to produce some grandiose design that treats anything awkward as a special case than it is to identify a simpler, more consistent underlying concept and then write simpler code to model that.

If both the original developers and the knowledge they had have been lost, then it is probably already too late to perform any major maintenance on this code base. The project has already entered its “servicing” stage.

At that point, you basically have two possible approaches that actually work: you can restrict maintenance to small-scale changes, which may be sufficient if the goal is just to keep the project ticking over for a while, or you can accept The Big Rewrite (which isn’t so big in this case) in order to get a project that can be properly maintained.

If you want to go down the tactical changes path, there are a couple of approaches to finding your way around the code.

If you’re familiar with the general field of the software, just not this particular code, then you can work top-down. Start with the key, high-level concepts you know the program implements, and try to find the code that represents those:

• Look at things like file names and directory structure (often a good starting point, because these tend to reflect the original design/intent behind the code).
• Get a tool like Doxygen to draw some graphs of the relationships between functions/classes in the code, and chances are the big clusters of related code will match some of the concepts you’re trying to find.
• Just search the code base for key words from the problem domain. Look for functions/modules/classes named after them, or that refer to them often.

Hopefully, if the code has a reasonable modular design and you just don’t know what it is yet, this sort of approach will identify the organisation of the code at a very coarse level, but then you can try to break down each area in more detail the same way.

Alternatively, you can work bottom-up. Find a significant starting point, such as:

• somewhere that generates some output you’re interested in
• somewhere that throws an exception or trips an assertion relevant to a bug you’re trying to fix
• a busy spot when you run the program through a profiler.

Examine the code near that point. Look at what kinds of data it works with. Look at what functions it calls, and what functions call it. Try to figure out the wider significance of the code you started with, and the other code to which it relates. Then move up a level: what is the purpose of all of that code collectively? Repeat until you’ve explored as far as you need to.

After some other discussions about these topics, I recently wrote up a couple of articles with some more background information than I’ve given here — link in my sig if anyone’s interested (though be warned that they are pretty long).

FWIW, in studies of the problems developers encounter in practice, one recurring difficulty is working out the motivation behind a given piece of code. This supports advice to comment why the code is written the way it is. See, for example:

• LaToza, Thomas D., et al, Maintaining Mental Models: A Study of Developer Work Habits, in ICSE '06: Proceedings of the 28th international conference on Software Engineering
• Ko, Andrew J., et al, Information Needs in Collocated Software Development Teams, in ICSE '07: Proceedings of the 29th international conference on Software Engineering

Both papers were coauthored by Robert DeLine and Gina Venolia of Microsoft Research.

In LaToza, 66% agreed that "understanding the rationale behind a piece of code" was a serious problem for them.

In Ko, "Why was the code implemented this way?" was the second most frequently unsatisfied information need among the developers observed.