Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What was the nicest codebase you've inherited without the original author(s)?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: What was the nicest codebase you've inherited without the original author(s)?

#21

Post by grigjd3 »

So if the codebase were good, I would not be assigned to it. However, I always look to fix the following issues:

1) lack of extensibility. This comes from poorly scoped projects. Both previous dev and product manager didn't understand the value in what they were making.

2) built in headaches. This is related to (1) but it's kind of the opposite problem. I see deployment tools that don't make the options object available to read in all contexts, or unhelpful automations, like silent failures. This is often from someone inexperienced trying to be clever.

3) terrible engineering practices - storing prebuilt native binaries in git, deploying a custom (read unsupported) version of a tool like gpg or perl. This can represent just a terrible engineering culture, but I often find these practices can be sourced to someone with a title like Director of Research

4) Lack of scalability - this is the least worrisome thing I run into. It takes experience in big problems to know ahead of time with any accuracy where the bottlenecks will show up. If this were the only problem I ever ran into, I'd be a happy camper.

Re: What was the nicest codebase you've inherited without the original author(s)?

#22

Post by sreque »

I didn't inherit them, but I've had to read through portions of the sqlite and Mercurial codebases and found both to be very well written. Good code can and does exist. It rarely exists in the private closed source sector, however, because teams either are unwilling to invest in it, lack the proper skills in their developers, or both.

Re: What was the nicest codebase you've inherited without the original author(s)?

#23

Post by geoka9 »

amoitnga wrote: post #8
Robin_Message wrote: post #3

19 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!

Wow, that's some wisdom right there :) +1. Whole new meaning to "best code is the one that doesn't exist".

Ken Thompson: "One of my most productive days was throwing away 1,000 lines of code."

Re: What was the nicest codebase you've inherited without the original author(s)?

#24

Post by drostie »

phkahler wrote: post #4
Robin_Message wrote: post #3

19 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!

All code is technical debt. We should not write it unless it serves a purpose of high enough value.

I like the idea but find that an overstatement that trivializes the nature of technical debt: at some level one is talking about things that "pay off now" but require "interest payments" in the future" and while one can kind of squeeze the line `for (let i = 0; i I think what's really at stake is that code and data are a sort of inventory: they are not what you are selling, but they get turned into what you are selling. Inventory always has a carrying cost, and generally people underestimate that because they are only looking at the direct cost of storage, not how the presence of the inventory itself gets in the way, makes getting to other things harder, makes bottlenecks harder to see.

And that's where you see that debt is a wrong metaphor, because debt has the particular property that you can pay all of it off and that would be a good thing. By contrast inventory is a good thing in the right place: It means that if one thing stops working, the system can still continue for a while. Really operating with zero inventory everywhere is possible, and it's not done because it would drive you out of business. Similarly, deleting all of your code is not accessible in the way that getting rid of all of your debts is.

Designing an API to have a separate messaging later from its business layer from its data management layer from its data fetching layer is a technical debt; the fact that any change in the system now needs to be distributed across 10 different places in the code base is your interest payment. I would argue that you would like to derive all of these from some shared source of truth to remove those interest payments, and when you do, I no longer think that it's a bad thing for you to have a homebrew HTTP framework that has those separations in its internal functions.

Re: What was the nicest codebase you've inherited without the original author(s)?

#25

Post by dustingetz »

Robin_Message wrote: post #3

19 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!

The better we get, the more complicated problems become barely within our reach

Re: What was the nicest codebase you've inherited without the original author(s)?

#26

Post by adius »

Code written in Haskell is often really easy to pick up. Due to it's pure functions it can easily be picked up function by function and the GHC repl gives you an easy but powerful way to poke around. Of course there are also the crazy type level EDSL libs which are hard to disect, but in general Haskell has been the best language for me to pick up code written by others.

Re: What was the nicest codebase you've inherited without the original author(s)?

#28

Post by ebiester »

Robin_Message wrote: post #3

19 upvotes, 1 hour, no answers... How often do you look at some code and think "an idiot wrote this", and then realise you're looking at your own code? Maybe all code is technical debt? That is, maybe every piece of code you inherit is bad because you now have more to learn and understand, no matter how nicely structured/documented/tested it is. Sorry OP, I got nothing positive!

The hard part is that the good codebases I've inherited were ones where I overlapped the original authors, or there was some chain of developers. Picking up a codebase with no context is relatively rare in my experience.

Re: What was the nicest codebase you've inherited without the original author(s)?

#29

Post by mattnewport »

I inherited EASTL (EA's internal implementation of the C++ STL designed to be more suitable for use in games) for a while after the original author left EA, although I'd already done some work on it while he was still there. It's now open source on GitHub. There's also a paper out there outlining the original motivation and design goals.

It was generally very well written and where it differs from the standard there's usually an interesting reason why. It had extensive unit tests that ran automatically across a very wide range of supported platforms and compilers including all major desktop, mobile and console platforms. It is generally much more legible than the STL implementation used by Microsoft (which was one of its design goals) while also often more efficient. It's the STL so it's mostly fundamental algorithms and data structures and widely useful utilities of general interest rather than very domain specific business logic.

Re: What was the nicest codebase you've inherited without the original author(s)?

#30

Post by perfmode »

fourthark wrote: post #11

I inherited a popular open source charting library. People like it because it has a data model - you can automatically brush and filter between charts. It is intentionally a leaky abstraction so that there is always a way to customize it if it doesn't work the way you want. There is only enough design to make it reusable, no claim to a "grammar" or other highfalutin abstractions. There have been dozens of contributor…

Plottable?
Post reply on HN