Live data from Hacker News

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

news.ycombinator.com

71–80 of 151 posts

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

#71
post #70
post #34

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…

> It is 14 years old Curious - what version of Rails is it running on?

When I joined, it was Rails 4. Since I've been there, we upgraded to 5 and are now about to start migrating to 6.

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

#73
I once worked on porting code for a several million line cobol application into Java. My part was a truly herculean set of complex business process (maybe 500kloc) and this task would've been damn near impossible if it wasn't for the fact that their code was immaculately consistent.

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

#74
I think we are typically not as good at spotting good code as we think we are.

For example, I inherited a large code base I while back and thought the classic "I can do better than this". After a few hours of hacking together a demo, only then could I appreciate the existing code base and how nice it actually was.

I think in general I look for a good level of abstraction - but not too an insane level. The best measure is how quickly you can understand it, and how long it takes for you to contribute to it.

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

#75

I would argue that a lot of the time, people do not inherit a "bad" codebase. They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs to survive long enough to be inherited by someone other than its original author. It's easy to spend a day with a codebase (that others spent years writing) and call it "bad". I'd argue it even feels pretty good to take that stance of superiority.…

Well, you can have a successful product with a better or worse code-base. Of course, if the product is successful, the code has to be good in some sense. But that doesn't mean that there aren't parts of it that are in bad shape.

For example, I've worked on a huge C# product that has been developed in various epochs by up to 100 people at a time. When I was working on it, it was around 10 years old. Certain parts of it were in good shape, others had stuff like a 5k+ line OnPaint() method for a table cell that was doing data processing in place and had stuff like "if ((value == -2) && (type == someTableType) && (userOptions.SomeFlag == SomeEnum) && (someOtherColumn.Value == "something")) { value = paintCheckBox(enabled) }" and such.

Of course, that code was doing what it was supposed to (at least in general), and it had gotten to this state during a really bad delay where bug fixes/features had to be churned out to reach an important release date - so in some sense it was "good". But in the sense of being possible to change without a major re-write (of that particular area I mean) or without introducing 3 bugs for obscure combinations of features, it was really bad code.

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

#76
I've inherited an internal application that handles some stuff for manufacturing written in .NET. (windows app, used by 100 people cca, 10k lines of OOP code roughly) The way it was written or actually re-written, allowed even for a non-programmer like me (at least not formally trained) to easily to implement all the changes.

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

#78
IMO, none of the things OP listed here are what makes code "good". Test coverage, documentation, organization, constant style, "best practices". You can have one or all of those aspects in any project and it can still be a nightmare to maintain.

What makes code good is "How hard is it to fix issues" and "How easy is it to understand". You can have well documented code which ultimately is hard to understand. You can have well organized code which ultimately makes fixing issues with said code hard.

In order to know if a code base is good, you have to experience maintaining it. You can't (easily) know a code base is bad with cursory glances to mental checkboxes about it.

The metric I use for good code now a days is "How often does this wake me up in the middle of the night?" Good code is code that doesn't cause my employer to pester me off hours.

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

#80

Not someone else's code but I had the strange experience recently of revisiting an old project of mine (DNS server written in typescript + deno) and being intimidated by the quality of my own 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…

revisiting an old project of mine (DNS server written in typescript + deno)

Can it really be called old considering the very modern tech stack?

Post reply on HN