Ask HN: Have you ever inherited a code base you thought was well done?

In my experience it usually is actually bad. The bad parts are most often not tradeoffs, but rather over-engineered complexity that could have been simple and improved development speed at the time too. Usually the issue is developers thinking of a bunch of things they might want to add in the future and implementing abstractions to make adding those things easy. But, of course, 1 out of 10 of those things ever actually end up getting built, and another 9 that were never planned for do, so the whole thing is a disaster since it was designed for X, but ends up being Y. This is entirely avoidable and can't be described as the traditional speed for ugliness tradeoff.

I've not gone through several inherited codebases. At first I called them awful --- however, as I've gotten older, I realize that code is harder to read than most people think. We are trained to follow a particular set of styles, linters, testing strategies, etc.

When we sit down to an inherited code base, we don't know what they were doing, so it looks terrible. There might be a very simple key that you'll never figure out until you've spent a lot of time reading the code. If you go adding code that doesn't jive with the hidden premises, there will be conflicts that you create, which you'll blame on the old code, even though it was your lack of understanding that created it.

What a great interview question!

Well said.

I recently inherited a code base which was developed by some devs-for-hire while the company started building up the team to take over (including me).

I met the last remaining dev-for-hire for the handover and got the impression that the company paid very very close attention to how many hours they billed and which meetings they were allowed to attend, and 0 attention to the code they produced as long as it worked.

Thankfully, the code was actually working well enough - and the thing that I appreciated most of all was the fact that at lots and lots of places in the code, there were frank comments like

    // This is completely undefined as of yet. I'm just implementing this how I think it should work, you can probably delete this and start over if it no longer makes sense.

So incredibly helpful. No Chesterton's fencing around, just clarity about the parts of the code everyone knew was just around to do its job, then get rid of.

Not exactly, but I have had 2 experiences that made me think it's possible:

1) I was working for a small company that did contracts related to graphics and printing. At some point we were asked to evaluate a MacOS (8 or 9) extension from Extensys. I don't recall what the extension did beyond the general thing that all extensions do, which is patch some system routines to update their functionality. But the code was incredibly clean and clear. Despite having never written a Mac system extension before and having only a vague understanding of the process of doing so, I was easily able to follow the code and understand how it worked. Unfortunately, we ended up not taking whatever the job was (probably just updating the extension for a more recent OS or something), so I didn't actually get to work on it.

2) Many years ago I sold some video filters for popular video editing programs (Final Cut Pro, After Effects, etc.). Eventually I sold my IP to a competitor and went to work for someone else. Fast forward ~12 years, and I'm at a trade show, when I see some 3rd company still selling my products! I don't know if that means my code was actually good, but it survived for at least 12 years after I stopped working on it, so I guess someone was at least able to figure it out.