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

Yes I have

The codebase I'm working on now is what I consider an exemplary Ruby on Rails project. It is 14 years old and still going strong. It is structured exactly like you'd expect a Rails project to be structured. The gems the authors chosen have been reliable so far with few exceptions. We regularly step into sections of code that are 5 or even 10 years old, and modify/extend them with no issue. Even brand new programmers (fresh out of boot camp) find it easy to work with. It is a success by all standards of software engineering.

Same here. But the one I'm using is 7 years old. Very nice code, some opportunities here and there, of course.

I always mention this when I'm hiring: our codebase is "old", but the code is actually well written and tested. I've seen worse code in projects that are just a couple of months old.

My current workplace has what I consider good codebases. Good coding standards, good abstractions, reusability, and performance. It has plenty of tricky areas and bits of code that are poorly written or confusing, but that doesn't change the overall picture. If you have a large codebase that many developers worked on over many years and it's still doing a good job and able to be worked on, you're doing alright.

I haven't inherited it, but I've been working on an experimental fork of Stockfish as a side project.

The code isn't exactly easy to understand, but that's inherent to the complexity of the domain. But there's a lot of elegance to a lot of the data structures and how well optimised they are for the problem at hand.

And Stockfish' way of utilising multiple cores is simply beautiful to me. There are all sorts of algorithms for parallellisation of the Principal Variation Search algorithm at the core of Stockfish's search, to do with distributing nodes between threads and so on and so forth.

If you go read Stockfish, it might seem like it's just running ncpu separate single-threaded searches. Because that really is what it's doing. Which seems crazy at first.

But what it does is it has a shared, effectively constant time(technically O(n) where n is 3, the number of entries per cluster) lookup hash table for caching search results, keyed by the node. And it's even lockless. And then each thread has its own set of statistics generated through search, which then influences the order in which that thread visits nodes because they're used for move ordering heuristics. And there's some other heuristics where the thread might jump straight from searching depth n to n+2, to inject some more randomness.

So there is a distribution of different nodes to different threads. It's just an emergent property of fairly simple things happening in each thread, whether they got a cache hit or miss, etc.

The reason this is so elegant is that the search algorithm itself is much simpler this way because it doesn't care about what other threads are doing. It looks at the transposition table, that's all, everything past that is good old single threaded programming. Then there's a very simple bit of code at the end that does a vote for the best move, based on evaluation and various other statistics(like the number of times the thread has changed its mind on the best move).

What excites me so much about this is that you could in theory do wildly different things in different threads. They only have to agree on what goes into the transposition table, what it means, and how to vote at the end. Stockfish doesn't do that, so that's one of the things I've been trying to explore in my own project.