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

Or was lucky enough that all the choices they made did not blow up yet.

I totally understand the value of technical debt. But I have also seen in the wild cases where people thought the codebase was great simply because they hadn't run into cases where its rotten core would be exposed.

Yet.

I hated it, on my young and inexperienced eyes “everything was a mess”. It didn’t follow any good practice. The code didn’t have any layer, most of the code was written in the view and it didn’t follow the DRY principle, it had just a few libraries to share some code, so there was a lot of repetition.

Of course, I started “improving” it. I chose a layered architecture, I wrote several generic classes to implement the repository pattern, since I was a solo developer it took me a while to migrate big pieces of code to my new implementation.

Bugs came and went and I started noticing something. Even though my implementation was “beautiful”. I hated to fix bugs on the new and “improved” code base. To debug I had to jump around a lot. The bug was always hidden. And sometimes my changes could affect other places in the code base so I had to be really careful. In the other hand fixing bugs in the old implementation was pretty straightforward and it rarely broke other places.

The project came to an end. The company bought a CRM that had more features so they shut the old code base down.

All my efforts to improve the code were a waste of time. They wasted my time, not only because it was not going to be used in the future, but because even if it lived longer my changes added unnecessary complexity to the code base. This complexity made it difficult to work on a really simple project, it made it fragile and it was simply not fun.

I learned a lot. I don’t judge code bases anymore. Now I can see the benefits of “ugly” code.

I had those familiar feelings of "I could never write code like this" or "I'd never have thought to do it like that!" or "This person must really know their shit". Turns out it was me all along and I'd just forgotten I'd done it all.

Grokking it and modifying it after 2-something years was actually simple as I'd left good comments, abstractions, and even reasonable unit test coverage (even integrated with GitHub actions that run on push) so changes were a breeze.

There has to be a life lesson there somewhere.

The thing that struck me about the code is how well scorched the whole thing is. Portability is great, structure is clean, comments are good. When I came in, there were no tests, so I started adding them, but overall it’s been the best code base I’ve gotten to work with.