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

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

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 151 posts

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

#101

Post by trebbble »

vinhboy wrote: post #87
tboyd47 wrote: 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…

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself).

IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a little of that sort of activity does so much damage.

Amazing for starting from scratch solo or with a very small team. Dangerous (mind: not necessarily bad, just dangerous) under basically all other scenarios, including ones that that sort of ideal situation might develop into. In particular, a great deal of discipline and excellent taste is required to maintain the kind of legibility and reliability other languages & frameworks can give you "for free".

I expect a Rails project has the best hope of remaining good at a business that's got solid funding for an in-house team from day 1, and has good retention for that team. However, lots of startups or experimental ventures by larger firms experience a lot of thrashing and turnover in the early days, and often go through one or more periods of heavy outsourcing, while also being the kind of resource-constrained enterprise for which Rails is extremely tempting.

Arguably Rails is still the right call for them, if it gets them to market fast, but those kinds of places consistently end up hit with slow, expensive, risky feature development just as they're starting to get traction, much earlier than the usual "eh, needing to replace this will be a good problem to have" phase, and part of that's because Rails falls apart so fast if you color outside the lines at all.

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

#102

Post by tobr »

ThePadawan wrote: post #88
Edd314159 wrote: post #27

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 said. I recently inherited a code base which was developed by some devs-for-hire while the company started building up the team to take over (including me). I met the last remaining dev-for-hire for the handover and got the impression that the company paid very very close attention to how many hours they billed and which meetings they were allowed to attend, and 0 attention to the code they produced as long as i…

> No Chesterton's fencing around

That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.

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

#103

Post by aeturnum »

All the time!

As for what that looks like - it's hard to say. I would not say I commonly find "good" documentation or organization. Sufficient test coverage has been common and extremely helpful (especially b/c tests are often implicit documentation about how functionality is expected to proceed).

I would generally say that well done code has a flow that follows the conventions of the languages & libraries that it uses. Being able to appreciate the flow means that, whatever direction you want to go, you know how to pivot from the current state.

When I get "bad" code it's code that I can't actually work on until I do weeks or months of work trying to understand what the original intent was.

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

#104

Post by jrochkind1 »

mattlondon wrote: post #46

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…

I've had that experience. I honestly sometimes worry I've peaked and am getting less good at figuring out how to compose good code as my brain ages.

I think I'm actually getting better at it, at least in some ways... but not totally sure there aren't others I'm not quite as brilliant.

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

#105

Post by physicles »

cr3ative wrote: post #7

Absolutely, 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.

I have a giant doc called rude-qa.md that has a bunch of questions an opinionated new hire (dev or manager) might ask about our architecture, followed by a brutally honest “here’s why we did it this way”. Often the answer is something along the lines of “I didn’t have enough experience designing systems back then. We could switch now but the cost is high and there’s not much benefit”. Humility is key. It really helps clarify my own thinking too.

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

#106

Post by oumua_don17 »

maerF0x0 wrote: post #89
Edd314159 wrote: post #27

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.…

> to survive long enough to be inherited by someone other than its original author. survival is far too low of a bar. We want delighted customers, low churn on employees, low minimum bar of required IQ to understand it (easier hiring, less stress), inexpensive modifications + improvements. Survival is only sufficient for cash strapped startups on borrowed time&money because if survival fails, then the future no longe…

>> soon as the future seems probable

The next target then is acquisition or an IPO which is then followed up by quarterly earnings. It’s always survival first unfortunately

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

#107

Post by jrochkind1 »

nailer wrote: post #31
cr3ative wrote: post #7

Absolutely, 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.

> why certain decisions were made; basically explaining anything which would raise an eyebrow. Yes! This is what comments (and READMEs etc) are for. Not explaining the what, ie how your programming language works (unless you're doing something most engineers wouldn't know). But explaining why they were made. // Workaround for https://github.com/org/project/issues/263

In the contemporary world with git online, often in github, where you can put an actual URL to an Issue, PR, or commit in a comment in sourcecode -- it's SO valuable.

I think this is actually one of the under-rated most valuable aspects of github (and probably other similar systems), things it's changed the most -- that everything has a URI that can be linked to, including in code comments. And a reason I could never deal with "just git and email patches" without a web UI that gives everything a URI that can be linked to from text.

I especially like leaving links to issues in third-party open source dependencies. If someone comes along later and wants to change the thing that was a workaround to a bug -- they are easily started on the trail to figure out if the bug has been fixed, in what version of the dependency, etc.

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

#108

Post by MiddleEndian »

vinhboy wrote: post #87
tboyd47 wrote: 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…

I might get a lot of flame for this, but I would say this is probably true of most Rails project because Rails has a lot of great standards (opinions). I am not sure why people hate Rails, I love it exactly for this reason.

I like Rails a lot and use it for my personal web-based projects. Rails (and Ruby in general) is (/are) great because of strong convention, as you mentioned.

But I would say that the danger is that you can break rules in bizarre unpredictable ways, which I've done myself and then gone WTF when going back to those projects years later.

It's also kind of annoying to set up and upgrade, lots of middleware to manage, but that's the case for almost every framework.

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

#109

Post by jrochkind1 »

cogman10 wrote: post #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 h…

I would say "simple changes are simple to make" is pretty much the whole goal of software design/architecture... and is actually really hard, you don't know for sure if you've hit it until you try, and is still a craft you get better at only by experience (especially including domain experience) not by following "best practices" or "design patterns".

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

#110

Post by jrochkind1 »

shtopointo wrote: post #59

Yes – I believe the author took the Design Patterns book and went to town. The classes were small ( What helped, I believe, was him coming from a Ruby / RoR background (extensive OOP usage) and the fact that this was his 2nd attempt at writing this, after he wrote a similar library in Ruby. I think about some code to this day and try to emulate wherever possible. Although I think the guy that wrote it was also a very…

> the fact that this was his 2nd attempt at writing this, after he wrote a similar library in Ruby.

I've seen and personally experienced that again and again.

While you don't always have the luxury of doing it, I think we make a bit too much from the "Second-syndrome effect" -- that says building it a second time will invariably be over-engineered -- and not enough from "build one to throw away" -- ironically both are from Fred Brooks.

Also under-estimate the value of domain knowledge, understanding the use cases and what needs to be done. If you've already built a thing (OR have intimate knowledge of a thing), and you know where it succeeded and failed, you can often use that knowledge to figure out the elegant design that will fail less and succeed more.

Post reply on HN