Software Lemons

If you buy a used car with the clear expectation that it runs, and then you find out a month later that it’s a piece of crap, that it needs a ton of repairs, you’re probably going to be pretty upset. This is a common enough thing that there’s a name for it: We call it selling someone a lemon. The car is the lemon. (It’s a common enough thing, in fact, that there are even laws against it in many states, called “lemon laws”.)

Some very common advice for avoiding a lemon: Have the car you’re buying inspected by an independent mechanic. Like programmers, auto mechanics are technicians, and they’re good at finding technical problems. Sign-off from good independent mechanic will give you a good deal of confidence in the soundness of your new used vehicle.

It’s interesting to me that I haven’t seen more of this independent review sort of thing done when it comes to custom software. Businesses often hire people to write custom software without having a strong ability to determine the quality of the software that they’re paying for. They can tell whether it works to the specifications, but those specifications are rarely as rigorous as they probably should be. Those specifications also frequently change over time, and the ability to make reasonable changes without great cost is a huge component of software quality. How can they tell whether their custom software can be changed reasonably easily? Basically: How can they tell whether they’re buying a lemon?

It seems to me that a review from a reputable third party would offer a fair amount of confidence, and wouldn’t be particularly expensive. Many experienced developers I know wouldn’t need a lot of time to look at your project and give a reasonable assessment of its quality. Like auto mechanics, programmers are technicians, and we’re good at finding technical problems. We probably wouldn’t turn up every possible specific problem in short order, but we could tell you pretty quickly whether you might be buying a lemon.