Programmers should not care about bad code

This is going to be controversial. And of course, the title is a little provocative. But that is not to say I don’t stand behind it. Programmers should not care about bad code. Programmers should care about bad interfaces.

And to some extent, all programmers already act as if this is true. Because nobody ever bothers to read the code to things that work. Nobody is going to tear open their compiler or interpreter, to make sure the code inside it is clean. Most developers don’t even open up their favorite libraries to make sure it’s clean code inside. And why would they? Those compilers, interpreters and libraries probably work, otherwise they wouldn’t be favorites.

And yet somehow, when it comes to code inside a project, we stop thinking like this. As soon as code is part of our own project, and not made by a respected third-party, we complain that code is ugly, or unmaintainable, or hard to read, or hard to use.

But why are these things so problematic? Is it an inherent issue that a block of code is ugly? Will your users notice it? I doubt it. Will the code mysteriously spread around, devouring other parts of the code? Unlikely. It’s just there, and it’s working fine. There’s no issue.

In fact, why are you even looking at the ugly code? There’s thousands of files in the project, hundreds of thousands of lines, many of which weren’t even written by your team, many of which haven’t been touched in months, or even years. Why are you looking specifically at this file with ugly code in it?

Actually, I probably know why you’re looking at the ugly code, fuming about how it’s ugly, unmaintainable, and messy. I know why you want to just delete all of it and reimplement it, in a cleaner way. And why you are ignoring the files around it, which probably also contain ugly code.

It’s because you are trying to use the code and the interface is also bad. Maybe there is simply no proper documentation for a function. Maybe it isn´t clear about the arguments it expects. Maybe you ended up in it because it doesn’t handle exceptions properly. Maybe you can’t find the return value, or don’t know how to change a setting in a class.

Whatever it is; you probably first tried to look at the documentation, maybe look at your IDE’s type-hints. But you still couldn’t figure it out. So you opened the file and… this code is ugly! Disgusting! It has to be rebuilt, right away!

Of course, that exact same code would have entirely escaped your notice, if your problem was solved by a simple documentation string in your IDE showing you how to use the function. You would not have stopped to care for even a moment about the ugly code if its interface was proper.

The programmer versus the computer

In the end, when you build software there are two very distinct entities that act on that software. Both care about very different things. The computer that runs your software doesn´t care about whether the code is ugly or clean, well designed or a huge mess. As long as it works, it works.

The programmers on the other hand, cares about the layout of the code. But a programmer can only keep in his head a miniscule fragment of a project. Mostly, we think in abstractions. In broad systems. In designs and system architecture. Not in lines of code.

So you would then expect programmers to care about interfaces very deeply, but not about the specific contents of a Class. As long as that Class is clear about what it does and about how you use it, does it really matter how it does it? Does it really matter that the Class makes a mess of its own internals, if it works?

I read a very powerful quote written by Alan Knight:

One of the great leaps in OO is to be able to answer the question “How does
this work?” with “I don’t care”.

While we all learn about this in all kinds of classes on programming, it seems to require more repeating regardless. The contents of a class should stay inside that Class. Each Class should be a self-contained block of code, that does one thing and does that thing well.

When you have that working, you almost never need to even open a class and look at how it works. You can use the internal implementation to benefit the computer; make it fast, make it effective, make it easy. A proper class basically shouldn’t need to be edited once it’s done, if any new functionality is desired it should be extended. And proper extension doesn’t really care about implementation either.

This allows you to build the code in such a work that it works well and proper, and then never touch it again. If the interface is good, nobody is going to look at it again. It’ll satisfy the interface and it’ll satisfy it well. Anyone will be able to use it.

And for that you’ll think it’s great, in the same way you think that about most of the libraries you are using in your projects right now. Because the computer doesn’t care about bad code, and the programmer should only be talking to its interface anyway.

Show your support

Clapping shows how much you appreciated Erik Roelofs’s story.