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

I've inherited code where I thought sections were well written, but probably not an entire project.

"good" is incredibly subjective, and subjectivity is temporal in nature. there been times when I thought code wasn't"good" at the time of inheritance, but several years later, found appreciation for it. Perhaps not enough to consider it good...but some appreciation.

I've tried to let go of classifying code as good or bad, or any other subjective means.

Non-exhaustive list of things I'm more concerned with these days:

- How long does it take for a new hire to onboard and be productive?

- How quickly are we able to respond with bug fixes?

- Do we have enough test tooling to have high enough fidelity coverage to say we've implemented something, or that an issue is fixed?

- How observable is it in production?

- How reproducible are any issues?

- How accurate is the documentation?

- Is there enough test coverage to be able to reimplement a portion with confidence?

You can probably take all of those things and distill it down into a "good/bad", but I think in general it's better to look at specific concerns that are managed over time.

I'm less concerned about the current state of the code, and far more concerned with how easily I can change the state of the code without incident.

> I see and hear a lot of complaints around inheriting code bases that are less than stellar.

I think this has to do with a common mindset among developers. If they don't immediately recognize familiar patterns and structures then it's the fault of the code. Many folks value readability and believe that code should be written for other humans to read and understand. Yet what we consider readable varies greatly among individuals, programming languages, and communities.

More experienced programmers won't be so easy to jump to conclusions. They may realize that it takes time to understand why code is written or structured a certain way. They recognize that it will take time to learn and appreciate the code.

However experienced programmers also develop a sense of taste and style. They build opinions based on experience and if they see a pattern in use that they associate with negatively then it's likely they will not have a good opinion of the code base.

Less experienced programmers are trying to build their sense of taste and style and will associate with whatever they perceive makes them superior. They often have an immediate and strong reaction to a code base. Their opinions and feedback are often couched in absolute terms.

Personally I've inherited great code bases. One of my favourites was a messy, old C++ web application written in the 90s by someone without much experience at the time. It didn't use any standard libraries, had no tests and documentation was non-existent. It used the file system as the database storing XML files all over the place. A single-threaded CGI application: something I wasn't unfamiliar with.

You would think I would have held my nose while dealing with this code base. Yet I consider it a good one because the team that came before me did a lot of work to wrap this monstrous code base in Python and started writing tests for it: a lot of tests.

Those tests enabled them to start synchronizing the data the application normally stores in XML files into a Postgres database. When I came on I had a completely different idea of what legacy software was. The engineer handing the project over to me gave me their dog-eared copy of Michael Feathers' Working Effectively with Legacy Code.

I like that code base because I learned a lot from it. I kept adding more tests and started adding more functionality and replacing the old C++ bits slowly but surely. Eventually we were able to get rid of the XML stuff, the email system, and replace it with Python code. The application was running the whole time and making the company money. It was a great learning experience.

One of the qualities I've come to value the most in an engineer is tenacity. When someone inherits a code base and can roll up their sleeves and make it something better than it was before: that's someone I want to work with.

Too many developers raise their hands, complain that this code is terrible, and suggest re-writing it. Or they burn out and find new jobs else where. Me? I like to stick around, figure things out, and make them go to 11.

I thought about this for a bit and came to the conclusion that I have, but not because the codebase knocked my socks off. Instead, the codebase didn't have any of the signs of bad practices. Most everything was where I expected it to be, there was sufficient, but not stifling test and review practices, etc. It felt natural to work within.

So I don't think that a good codebase does any one particular thing well, it just avoids the bad parts of bad codebases. Via negativa in practice.

I'm in a surprising situation right now: I've just inherited a huge, well written C# .NET project that's not generating much value to the business. Too much boilerplate, too much unused models and extensions. Things like that. It's weird because every single piece of code seems well written and well documented, but this mammoth solves a very small part of a small business, leaving the internal users to reach out to spreadsheets most of the time.

Yes, but also it wasn't really a codebase? It was a compilation of Ansible roles, perl and bash scripts who all made sense and worked with each other, but it wasn't like a singular application. You still had to manually write your json configuration and then execute the Ansible that called the right scripts.

I think the reason it was good is that nothing was too integrated. You had of course scripts who integrated multiple others (mostly Ansible roles tbh), and that could be complex to understand, but everything else was great.

So: keep everything small?