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

131–140 of 151 posts

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

#131

Post by trebbble »

tboyd47 wrote: post #130
trebbble wrote: post #128

Earlier quoted context omitted.

> The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere. Noooooo. A ton of things simply aren't defined until the program's running. "What even is this?" is frequently a question that's hard to answer without running the project (hope it's in a runnable state,…

> Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain Funny, none of those things sound bad to me, but just like part of the job :D Could be Stockholm Syndrome?

It's part of the job with Rails. In many other ecosystems your tools just tell you the answer immediately, or you can at least easily grep your way to an answer.

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

#132

Post by bmitc »

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

> I would argue that a lot of the time, people do not inherit a "bad" codebase.

I think that's underselling the problem. A bad codebase is a codebase that isn't what it should be. Just because there are reasons, even legitimate reasons, as to why the codebase is what it is, that doesn't mean it isn't bad. Constraints can be bad and bad constraints make a bad codebase.

In my opinion, thorough documentation is a minimum. If a codebase doesn't have documentation, then it is automatically bad.

Software/programming/whatever you want to call it is about three things: (1) instructing a computer, (2) communicating between humans, (3) encoding knowledge of a domain. If a codebase fails at any one of those three, then it is a bad codebase. Too often, people only view a codebase in the lens of (1), in that if for the most part it does the thing it's supposed to, then that's enough.

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

#133

Post by wizofaus »

jvalencia wrote: post #84

I've not gone through several inherited codebases. At first I called them awful --- however, as I've gotten older, I realize that code is harder to read than most people think. We are trained to follow a particular set of styles, linters, testing strategies, etc. When we sit down to an inherited code base, we don't know what they were doing, so it looks terrible. There might be a very simple key that you'll never fig…

My experience recently (3 or 4 separate projects) has been the opposite - at first the code looked fairly neat and well organized with few obvious smells, but the more I worked with it I realised how many functions/modules were poorly named and/or handled bits of unrelated functionality in a single place or adopted inconsistent conventions or made unnecessary assumptions or relied heavily on global variables (or the equivalent thereof). The best code I've worked with has generally been open source libraries that have well- defined limits to their functional scope.

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

#134

Post by idrios »

chrsig wrote: post #22

I've inherited code where I thought sections were well written, but probably not an entire project. "good" is incredibly subjective, and subjectivity is temporal in nature. there been times when I thought code wasn't"good" at the time of inheritance , but several years later, found appreciation for it. Perhaps not enough to consider it good ...but some appreciation. I've tried to let go of classifying code as good or…

A relevant adage that has stuck with me is "a bad implementation of a good abstraction means you'll just need to rewrite all the parts that are poorly implemented. A good implementation of a bad abstraction means you need to throw away the whole project."

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

#135

Post by alexdowad »

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

Good points. Further, a codebase which has survived for a significant period of time is probably one which has created (and is creating) a lot of value for people. If it didn't do anything valuable or useful, it would already have been discarded.

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

#136

Post by barking_biscuit »

shakna wrote: post #14

I worked on some ancient FORTRAN for CommBank (formerly Commonwealth Bank of Australia). Most of the details are still under NDAs, but the project was amazing. Every variable and function was explained in a series of physical manuals in excruciating, and up-to-date, detail. The manuals had index lists by name, function, type and concept, making it ridiculously easy to find exactly what you were looking for. The docum…

>A single complaint from a coworker or customer can land you in front of a review board. But the work they produced, at least what I saw, is absolutely worth it.

Holy crap. Not sure whether I would love this or be destroyed by it haha.

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

#137

Post by bluenose69 »

I like seeing (through git-blame or similar) sections of code that were written after-the-fact by a new coder, but that still fit in seamlessly.

I don't mean just in terms of indentation, variable-naming, etc., but also in deeper ways, such as decisions about when to create new functions or extend object structures. Other clues relate to decisions about balancing code flexibility and execution speed, and also about what steps along the journey require road signs.

It's hard to define these things, but I find that the quality of code integration becomes evident when I'm sufficiently immersed in the code that takes the form of a communication between coders.

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

#138

Post by heywoodlh »

tobr wrote: post #102
ThePadawan wrote: post #88

Earlier quoted context omitted.

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.

> Avoid unintentionally erecting Chesterton's fences

This is a great rule of thumb. I often find I unintentionally do that all the time and then I have to figure out why I did something I did. Trying to avoid that with good comments, documentation, etc. earlier in my career would have been a great practice.

I find I often think something is so common-sensical that I would never forget and then come back a while later and have completely forgotten.

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

#139

Post by blacksoil »

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

> But you're viewing it with literally zero of the context of the time in which it was written. You see none of the constraints, none of the pressures, none of the alternatives presented in the moment.

While this is true and compassionate, I think bad code is still a bad code. It'd be dishonest to call a bad code a good code.

I agree though that from time to time circumstances simply wouldn't allow developers to take the time to write good code and/or address tech debts. This problem I feel would need to be catered at management level. If companies were to attract great talents, they would need to maintain certain standard of code quality and empower their developers to do clean ups/refactors every once in a while.

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

#140

Post by nucleardog »

eloff wrote: post #10

Wait, 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 jo…

I started a job where two months in I assigned myself the task of cleaning up one of the major codebases. In the span of about three weeks I collected a bunch of metrics, parsed through a bunch of logs, customized some static analysis tools to fit in with a bunch of non-idiomatic stuff we were doing everywhere… and deleted most of the codebase.

For about a week my daily standup would be something along the lines of “I deleted 34,000 lines of code yesterday.”

In the end I think I threw away about 200k lines out of 350k.

In the span of the next few months I think we ended up identifying one method I’d removed that was still in use.

And qu’elle-surprise, the team’s velocity picked way up, people were suddenly way more willing to make bigger changes or even refactor, etc. People just really needed to get picked up out of the hole far enough that they could see the light and they ran with it from there.

It never became _good_ code, but it became much more manageable. Even if you can’t justify good code for the sake of good code, code good enough to actually be worked on is a must.

Post reply on HN