“It’s ugly but it works” is a statement I’ve heard kind of a lot in programming. On the surface it sounds like it represents some sort of reasonable pragmatism. “I got this code working and I’m not going to waste a bunch of time gold-plating it”.

I really dislike this saying, though. There are two reasons why.

“Ugly” is just a euphemism for “hard to understand”

When a programmer refers to a piece of their own code as “ugly”, what they usually actually mean is that it’s hard to understand. “It’s ugly but it works” is a much more defensible-sounding statement than “It’s hard to understand but it works”.

“It works” is only half the job of code

In Refactoring, Martin Fowler wrote, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

The reason that it’s important for humans to be able to understand code is of course because it’s humans who are responsible for maintaining the code. If a piece of code works but is impossible to understand, then it’s going to be a lot more time consuming and expensive to maintain.

“But what about deadlines?”

Sometimes time pressure drives programmers to cut corners and write worse code than they could. I’ve certainly done it.

I would argue though that I usually don’t find writing bad code advantageous for the purpose of meeting deadlines. In fact, I tend to find that I can write code faster if I not only focus on code quality but clean up some of the existing code before adding new code. Consciously incurring technical debt in order to meet a deadline usually just makes the next deadline even harder to meet.