Skip to content

Car Manufacturers: Where are your regression tests?

December 4, 2009

I recently part-exchanged my old, small car (let’s say, Ford Fiesta*) for a newer, bigger car from the same manufacturer (let’s say, Ford Focus**). Whilst the newer car is better in many different ways, it’s somewhat disappointing to find that a number of useful features in the original have been lost in the intervening years.

Fumbling in the dark

My old car had two buttons on its remote; lock and unlock. Whilst they were both the same size, the lock button had a picture of a key embossed on its surface. On a dark night, or even with the key in your pocket, it was easy to just brush the buttons with your thumb, and immediately tell which button would unlock the car, and which would lock it.

My new key-fob has three buttons, and whilst the middle one (for opening the boot) is raised, the top and bottom buttons (for locking and unlocking) are identical. Not only that, but the fob itself is symmetric, and so there’s no way of telling which button is which without taking it out of your pocket and squinting at it under the nearest streetlight. Urgh.

Balancing Act

Like many cars, my old car had a metal flap that covered the fuel filler cap (the flap being the bit of metal that was the same colour as the rest of the car; the cap being the bit you’d unscrew and hold to one side whilst you put fuel in). On my old car, the cap had two grooves in the lip round the edge, and you could hook the cap on the edge of the flap so that you didn’t have to hold onto it (or have it scrape your bodywork) whilst you filled the tank.

My new car still has a metal flap that covers the fuel filler cap, and still has grooves in the cap to hook it over the edge of the flap whilst filling the tank. So what’s the problem? Well, the flap on the old car was square, but the flap on my new car is round. How am I supposed to balance a fuel cap on a rounded edge? What’s the point of having two grooves in the back of the filler cap, when it’s only possible to hook one of them over the edge of the flap? Urgh.

What has this got to do with regression tests?

Back in 2000 when my old car was being made, someone came up with the great idea of embossing the lock button on the remote, and someone else came up with the equally useful proposal of being able to hook your filler cap on the filler flap so that it was out of the way when you filled up. Those were great ideas, but they’ve been lost. Could this have been avoided? Sure; the manufacturer could’ve kept a list of all the great ideas they had for all the individual parts of the car, and when it came round to designing and manufacturing a new model, someone could go through that list of ideas and make sure all of them got implemented on the new design.

For all I know, they already do this, but either ideas get forgotten, or by the time it comes to check whether good old ideas have made it into the new model, it’s too late to make drastic changes like redesigning the filler flap or key-fob.

With software, we can be much more thorough. We can have a whole bunch of automated regression tests, like shouldBalanceCapOnFlap() and shouldDifferentiateKeyfobButtonsByTouch(), and we can run these tests all the time. We don’t even have to wait for the design team to give us a prototype; we can start with the tests and then design the prototype to ensure that the tests are passed.

Even better, once we have our software for a well-tested fuel flap or key-fob, we can reuse that element everywhere. So long as our interfaces are good (and we can even adapt them if they aren’t) then every car can use the same type of key-fob. Add continuous deployment into the equation, and not only can you improve your key-fob for every new car that you ever make from now on, you can improve it for every car that you ever made before too.

I should probably say something about DRY, and dependency management, and open source libraries. I should also probably say something about how to write good regression tests; how to write good unit tests. But I won’t; it’s too late on a Friday, and I’m not even sure I’d be qualified to talk about it anyway.

All I will say is this:

  • Writing good tests is hard.
  • Continuous deployment is worth it.
  • Favour other people’s code over your own (but make sure you adapt their interfaces).
  • Read some books.

There you go. That’s four more posts that I won’t get round to writing.

*It wasn’t.

**It’s not.

6 Comments leave one →
  1. December 7, 2009 2:35 pm

    I’m struggling to imagine how your keyfob requires you to look at it. Surely you can feel where the fob is attached to your key ring, and therefore know which end it the top? Post a picture.

  2. December 7, 2009 2:44 pm

    Yes, because learning which end is lock and which unlock based on the attachment of the keyring is much more intuitive…

    (Somewhat depressingly, this is how I’ve learned to use it. But I have to think about it every time. Urgh. Don’t make me think!)

  3. December 7, 2009 3:05 pm

    Ahh, I see. My fob is confusing too and I have just had to learn that the unlock button is the one in the top right.

    It’s a pretty simple state machine. You want to toggle between “Locked” and “Unlocked” so why don’t they just give you one button. A visual indicator of the cars current state helps for the times when you look back and can’t remember if you locked the car (flashing red LED on dash for example).

    I’d also like it if my car made a different sound or flashed differently for each of the state transitions (locking and unlocking). My Roomba vacuum has very intuitive beeps for a range of states using just a small set of possible tones. I don’t want “Pimp My Ride”, I want “Anthropomorphise My Car”.

  4. December 7, 2009 3:23 pm

    Yes, but you have a stupid car, so I’d expect you to have a stupid keyfob to go with it 😉

    My old car used to flash it’s indicators differently (once for lock, twice for unlock). I’m not sure what the new car does; I’ll have to give it a go later.

    Interestingly enough, my new car has fewer indicators (in the general sense) of its unlocked state, and that’s exactly what I want. My old car had knobs-on-sticks in each door that shot up when the car was unlocked. These were visible through each of the windows, and any opportunistic thief walking past could easily see if/when I’d left the car unlocked. With my new car, the only indicator is a small LED that flashes when locked, and even then isn’t very obvious. Now the thief has to try the handle to see if it’s open (and what sort of opportunistic thief draws attention to themselves by trying the door handles of every car that they walk past?). Sure, it’s not flawless, but it an (iterative, imperfect) improvement.

    Also, I don’t agree with your “one button for both state transitions” proposal, either. I want an “I don’t care what state you were in, I want you locked” button, and an “I don’t care what state you were in, I want you unlocked” button. I don’t want to have to push a button and then interpret the result; I want to know what’s going to happen before I’ve pressed the button, and then have confidence in it happening.

  5. January 13, 2010 10:00 am

    nice post and very nicely abstracted. very interesting way to break people into these concepts, might steal some of this in the future if thats ok – obviously i’ll attribute if i ever repost?


  6. January 13, 2010 10:37 am

    On the single button argument, how would you doublelock it with a single button? would that be effectively a double-click?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: