Ugly code may be very valuable, depending on why it’s ugly. I’m not saying that it’s good for code to be ugly, but that code that is already ugly may be valuable.
Some of the ugliest code was started by someone who knew the problem domain well but did not know how to write maintainable code. It may implicitly contain information that is not explicitly codified anywhere else. It may contain information the original programmer isn’t even consciously aware of. It’s often easier to clean up the code than to surface the information it contains using any other source.
Another way code gets ugly is undisciplined modification by multiple programmers over a long period of time. In that case the code has proved to be useful. It’s the opposite of Field of Dreams code that you hope will be used if you build it.
Working effectively with legacy code is hard. It may be easier, and certainly more pleasant, to start from scratch. Even so, there may be more to learn from the old code than is immediately obvious.
***
This post was motivated by looking to extend some code I use in my business. It wouldn’t win a beauty pageant, but it’s very useful.
Writing this post reminded me of a post Productive Productivity that I wrote a while back. From that post:
The scripts that have been most useful are of zero interest to anyone else because they are very specific to my work. I imagine that’s true of most scripts ever written.
Vernor Vinge has a wonderful description of a programmer performing “code archeology” in his sci-fi novel, A Deepness in the Sky. A snippet:
> The wonder of it—the horror of it, Sura said—was that unlike the useless wrecks of Canberra’s past, these programs still worked! And via a million million circuitous threads of inheritance, many of the oldest programs still ran in the bowels of the Qeng Ho system. (…) We should rewrite it all,” said Pham. “It’s been done,” said Sura (…) “It’s been tried,” corrected Bret, just back from the freezers. “But even the top levels of fleet system code are enormous. You and a thousand of your friends would have to work for a century or so to reproduce it.” Trinli grinned evilly. “And guess what—even if you did, by the time you finished, you’d have your own set of inconsistencies.“ (…) lately, I’ve been doing my share of archeology. It seems that five hundred years ago, a similar thing happened after an in-system war at Torma. They hacked together a temperature maintenance package that is precisely what we need.” “Almost precisely.”
When working with old codebases, especially when trudging through the git history, I often feel like I’m doing code archeology. Figuring out why certain choices were made, which conditions are still applicable, what are the unstated “obvious” assumptions. Ugly code can have real good reason for its quirks. I’m sure much of my code will be viewed as ugly old code in the not so distant future, possibly even by me. I guess I hope it’ll remain ugly and useful for years to come.
Back when I was doing R&D on new sensors based on “Novel Physics”, my job was to take a “proof of concept” lab prototype (often consuming racks of equipment and yards of bench), and see if it could be ported and packaged into an Alpha prototype lab instrument as the first step in evaluating the sensor as a potential product.
The software I wrote was the minimum needed to make the resulting prototype system work on cobbled-together hardware. If the prototype looked promising, Engineering would vastly improve and optimize my efforts to make a Beta prototype. My C/C++ code was intended as crude documentation, but to my horror I found it had made its way into the Beta prototype with minimal modification.
That’s when I intentionally switched all my prototype development to Python, to ensure at least some minimal Engineering effort would be needed to move it forward.
That worked for a couple years, until various Python speed-up efforts let Engineering consider deploying real-time Python code. Sigh.