the well-bred grapefruit

Typically I despise the “software development is engineering” analogy. The process of developing software is so very little like building a bridge or building a house (in any modern sense, at least) that it often seems to cause more harm than good to make the comparison in the first place. But last night Erin was watching a show on HGTV, and I realized that there is a rather striking analogy that makes sense:

Looking over poorly-written software is much like looking over a poorly-constructed house.

On the outside, the house may look fine; it may even be the nicest looking house on the block. If you talk to the people living in the house, they may say that they love the house, except for a couple of minor things that need fixing (after all, they hired you for something, right?).

Once you get in and start inspecting the house’s internals, though, you start to see problems. Electrical wiring is backwards. Gas lines are run through dangerous and/or illegal areas. Drainage is poor at best, and you see signs that the foundation has been eroding away. There are patches of insulation that are flat-out missing from the walls. Load-bearing structures aren’t built with the appropriate materials. The plumbing is a tangled mesh of rusting copper. The house is unsafe, and unless it receives a lot of attention from someone who knows what they’re doing, it won’t really be safe any time soon.

Software can be a lot like that. On the outside, it can look like a very attractive piece of software, and the users can really enjoy using it (except for a couple of things that they’d like you to change, but that’s easy, right?).

Once you get inside the code, though, you can find a fragile mess. Poor error handling, convoluted logic that doesn’t cover all the use cases. There are comments in the code that are less than useless because they’re totally wrong about what the code does or why it’s doing it. Application data isn’t always handled safely. The application tries to behave concurrently but most of the operations aren’t thread-safe. To top it all off, there’s no documentation and even less automated tests, which means you have no idea how the program is supposed to work, and even if you did know that, you would have no way to verify that it was working properly.

In both cases, when you take this information to the client, the typical response is going to be “but it works, why should I pay you to fix it?” Of course, when you’re talking about houses, the response is “because your house isn’t up to the code that’s mandated by law, and above that if some of these safety issues aren’t resolved, you and your family are exposed to serious risks to your health and safety.” When you’re talking about software, the best answer you can give is “Well, I know it hasn’t caused you any problems yet, but it’s highly likely that it will in the future unless you let me rework it for you.”

In other words, where the opinions of a general contractor can be backed by physical evidence and codes and regulations, even though the house appears safe, the opinions of a programmer can only be backed by the opinions of the programmer unless there’s a demonstrable problem with the software. There’s no easy way to convince a client that there are fundamental flaws with their code, and even if you do there’s no way to convince them it’s worth training unless they already trust you and have bought into your expertise on coding.

Wouldn’t it be nice if we - as an industry - had a set of codes and regulations we could leverage to improve software? I’m not sure what those regulations would look like, or how we’d enforce them - software developers can’t agree on how many spaces to use for indentation, much less on whether they should write automated tests - but I think it’s something worth thinking about. Nothing unnecessary or specific - no “you must use x testing library,” or “you must have all your software developers in one room,” because those only serve specific agendas. Nothing that requires ‘certification’ or anything else that can be used to make money; probably just some sort of open-source document that programmers can recognize as an authority on, generally, how things should be done. Imagine how much better our industry could be if we tried to standardize on disciplines that take steps towards preventing disaster projects, and were able to use those standards to convince clients that their software needs to be made better?

Would it mean that the client would always let  us make these changes? Of course not. There’s a lot less risk in the statement that “your program might crash often” than there is in the statement that “your house might burn down.” Also, I’d like to hope that no codes we create would ever be legally binding. What it would do, however, is lend strength to what you bring to the client; rather than it being you saying “You should pay me to fix these problems that you don’t really understand, but trust me, they’re problems,” there can be an industry-sanctioned document that says “Here’s the problem this programmer is telling you about, here’s why it’s a problem, and here are the risks you should consider before you decide whether to let him fix it for you.”

Just a thought… maybe a crazy one at that. But, just like a contractor who comes in and works on a house, your reputation becomes tied to every piece of software you touch. Wouldn’t it be nice if you had some better tools to convince clients that the code they have needs to be fixed?