I see and hear a lot of complaints around inheriting code bases that are less than stellar. If anyone has, I'd love to hear about cases where you inherited a "good" code base, whatever that may mean: awesome test coverage, good documentation, solid organization, consistent styling/formatting, abundant best practices, whatever!
Ask HN: Have you ever inherited a code base you thought was well done?
1–10 of 151 posts
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#2on first glance, no.
after a sufficient time spent meditating on the construction techniques of that project’s chesterton’s fence, most codebases i’ve seen become much more reasonable. Once i’ve spent enough time using it myself instead of just reading it, design decisions or organic evolutions start to make sense.
A good-faith humility is a good attitude to have as a reader, but it only really comes with professional maturity. Un-curling the sneering lip most of us seem to pick up in our late teens takes, in my experience, about a decade in a relatively attentive person.
some are still truly horrific, but they’re relatively rare.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#3Like asking your wife if any of her in-laws are good looking.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#4Inherited an awful stack of hacks once; given a list of names it printed "hello my name is" badges on a dot matrix printer. In a big, friendly font. This was before PrintShop [1], some little single purpose app running on Victor 9000 "almost PC compatibles" under DOS 2.
The list came out of a COBOL "DBMS" system that had a 64kb table limit. They had more names to print than that.
The stack of hacks consisted of scripts that ran trough all the tables of the "members list" DB (multiple floppies were doable, by the time i got it they had a hard drive), creating text "dump" files of the bits that went to the printer; more scripts to assemble those dumps and reformat them (in GWBASIC), and finally a script that fed one record at a time through the pretty printer formatting program and printed it out.
My contribution was figuring out a way to feed the "pretty printer" multiple records per run; instead of invoking the chain once per record. saved days for the entire print run.
It was a horrible stack and it wasn't fun to work with and I cussed the people who had implemented it; however: given the constraints when it was built and the resources of the people using it; it was incredibly cool. Until I saw it I'd have said it wasn't possible with that collection of parts, but it functioned as required and did so for a decade. Eventually it was replaced with WordPerfect doing a mail merge operation; the people wearing the name badges complained that the font wasn't as pretty.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#5Not even my own.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#6good codebase is like a dream that never happened but always wanted
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#7Absolutely, and there's a common thread in them: context. When I'm preparing to hand a project over, the README will be updated with design constraints (maybe even the RFC/project launch documents), why certain decisions were made; basically explaining anything which would raise an eyebrow.
I do this because I received a project with this note, and it stuck with me as an excellent idea; a letter to future explorers.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#8Yes.
It wasn't that the code itself was badly or well written so much as the concepts of how each process was isolated from each other, the communication protocol was well established and the external dependencies were kept to a minimum.
Data structures were chosen for ease of understanding rather than (run-time) efficiency which was the appropriate choice for this application. The application(s) relied heavily on various other scripts and the operating system to establish a (secure) network communication, offloading a lot of the complexity from the application to the operating system (where it belongs, in my opinion).
I recently update/ported the code base to work on more modern hardware and, besides some minimal updates and fixes, it worked well.
The code base was 10+ years old and mostly written in a combination of C and shell.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#9Yep, all of the above! The main front end code base at the company I joined earlier this year (https://deep6.ai/) is excellent. It is some of the best code I've worked with in my 13 year career. A lot of thought and care went into its design, implementation, and stewardship. The early investments that were made into the TypeScript-based project's quality make it very easy to extend, iterate on, and improve.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#10Wait, that's an option in the probability space?
Actually once I was lucky enough to join a company where the code was written well, had good test coverage, the team implemented good code reviews, required tests on bug fixes and features, etc. The pandemic was the five hundred year storm to their leveraged business model (hospitality business targeting business travelers) and they folded within months.
At the next job I created the backend code from scratch and was the primary maintainer. I left it in pretty good shape with good test coverage. There were plenty of things I'd have done differently given the chance though. Hopefully the next guy doesn't curse me.
At the current job things are a mess again. I'm working on improving it. Git blame has me at having modified/added 8000 lines in the backend Python code since I joined three months ago. Slowly digging out of the hole as it caves in around me.