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

Ask HN: Have you ever inherited a codebase nobody on the team could understand?

news.ycombinator.com

Post reply on HN
Print view View original

201–210 of 222 posts

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#201

Post by ConceptJunkie »

edw519 wrote: post #81

Oh yes, many times! I used to joke, "Why do I always inherit stuff like this?" and my mentor would respond, "Because companies with good code bases don't hire very often; their people are all so happy." How I have dealt with it: 1. Never complain. Never bad mouth any of my predecessors. Whatever they did wrong, I probably did somewhere else just as badly. We all have. 2. Never be bashful about what is wrong. Be objec…

The problem is that "If they need [to be] convinced, they are part of the problem." is the biggest reason these kinds of projects happen in the first place.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#202

Post by ConceptJunkie »

krylon wrote: post #196
edw519 wrote: post #81

Oh yes, many times! I used to joke, "Why do I always inherit stuff like this?" and my mentor would respond, "Because companies with good code bases don't hire very often; their people are all so happy." How I have dealt with it: 1. Never complain. Never bad mouth any of my predecessors. Whatever they did wrong, I probably did somewhere else just as badly. We all have. 2. Never be bashful about what is wrong. Be objec…

> Rename variables EXACTLY what they are. I have this coworker who has this terrible habit of giving the most meaningless names imaginable. Local variables are often just named "tmp". Or maybe tmpNum if it is a number. We are writing a program to implement various tasks as background threads, and the classes have names like "Process01", "Process02", etc. At one place, he declared five or six constants with SQL querie…

Naming things correctly and consistently is at least 50% of good coding, and at 90% of programmers fail at it.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#203

Post by hinkley »

kokokokoko wrote: post #62

I would be careful with some of the responses here. Over my career I've found that a significant subset of developers struggle with unfamiliar codebases. Sometimes this has to do with their experience being mostly with greenfield projects and other times it is because they have not seen a wide array of different work created by other people. But sometimes it is good old fashioned workplace politics. It is risky to ta…

The first step is admitting you have a problem. If you can’t acknowledge badness as a group then entropy takes over.

I complain/observe about codebases all the time, especially on projects with an SLA. It’s bit like fire code. When the shit hits the fan you [don’t] want people wandering around trying to figure stuff out.

Hallmark of a bad team (project management, really) is if the same three people are required for every emergency.

The interesting thing about complaining is that nobody wants to talk to the optimist about problems. It makes them feel small and stupid.

I find myself in the role of troubleshooter often, because I’m good at it, I acknowledge that the struggle is real, and at the end I try to summarize the experience, and diagnose where they went off the rails.

When you see 20% of the team have the same stumble, the problem isn’t with them. If the stumble was expensive then it needs to be addressed rather than blaming the victim. Nobody wants to talk to someone who shames them, either.

But I don’t believe in the classic rewrite. I believe in prevention and station keeping (don’t let it get that bad). The human brain can only deal with so much. If you want to keep adding to the project you have to keep cleaning old code and improving your practices. Slowly you’ll have a very different codebase, and a team where everyone senior can fix most problems.

Edit: a word

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#204

Post by hinkley »

ohyes wrote: post #193
celdon25 wrote: post #131

Earlier quoted context omitted.

> My number 1 red flag of working with a developer, unless they are very early in their career, is hearing them describe a codebase as awful. Most really are not that bad and are usually just using unfamiliar and less than ideal design patterns and coding practices. So, what if in reality, the codebase IS awful, and the product itself suffers from delays and setbacks even on seemingly simple tasks? Still a red flag i…

It’s always awful. That means it’s never worth it to discuss how awful it is. You’re probably working with people who helped produce the awfulness, and it pays to be empathetic towards your coworkers. Code isn’t produced in a vacuum and there are always external pressures for why this was hacked in rather than done correctly. It just kind of makes you come off as tone deaf and inexperienced. “My code is perfect and e…

> Code isn’t produced in a vacuum and there are always external pressures for why this was hacked in rather than done correctly.

Everybody has reasons for everything they do. Even if those reasons were made up after the fact to match the evidence (everybody wants to be sane even - no, especially - when they subconsciously do crazy stuff).

Anyone attempting self improvement has to first contend with the fact that their reasons are somewhere on a spectrum from wrong to excuses.

From a business perspective if you can tell me why it’s helping the business that’s the only reason that matters.

Also a very important life lesson to realize that the reason we did something isn’t a reason to keep it around. Sort of a “what have you don’t for me lately”. Hacking something four years ago to land a contract that saved the company isn’t a good reason to keep that code now. We did it because we did it, but we don’t have to keep it that way.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#205

Post by ashrk »

sethammons wrote: post #192
ashrk wrote: post #164

Earlier quoted context omitted.

Sure, and man are the easy wins satisfying. Fixing shitty data access methods/patterns is one of the easiest ways to get a "WOW!" out of a client or product owner if you're stuck in the low-visibility silo of backend dev[0]. I've just been repeatedly surprised over the years at how very, very many people are making real money, and consistently finding work, yet don't seem to know which way is up. And I don't mean gre…

What are higher visibility pastures that is not web frontend?

Mobile, probably a lot of data-analysis jobs provided you get to present results. Desktop work if you can get it. Non-traditional UI like voice. You can spend (what will seem like) a silly amount of time selling what you've done in backend work, even, it's just a harder path.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#206

Post by ashrk »

MichaelMoser123 wrote: post #190
ashrk wrote: post #88

Earlier quoted context omitted.

No (or long-broken) tests and no easy (at least partially automated and otherwise documented) way to build and/or run the code locally are the norm for others' codebases I've inherited. Those two things qualify it as "awful" I'd say, all on their own. Especially in languages like Ruby or JS where you're practically crippled in an unfamiliar codebase without tests and/or being able to poke around in the running applic…

Awesome! Here are some practical problems that used to give me headache, can you give us some best practices on how deal with these situations? - untyped languages that run through A LOT of layers of wrappers/indirections to get things done; How do you keep track? (with typed languages it is easier to figure where the next step is going to; though code in java likes to do this trick - it then obscures the details by…

In order—and mind I'm not like amazing at this so take none of this as best practice:

- Stepping through with a debugger. Static analysis call graphs in stricter languages[0]. Runtime call traces and visualization in dynamic languages. Often you can find some tool for it[0]. If it's that bad you're probably not gonna be able keep your head wrapped around it long term, so you'll be falling back on those tools often until/unless you refactor.

- Similar. Find a way to trace requests (you are really, really gonna want such a tool when things go wrong anyway if you're microservice-heavy) and record what happens, if it's so confusing you can't figure it out otherwise.

- Not much to do but isolate and replace piece by piece or screen by screen as the opportunity presents itself. Hardest part of this is that your new stuff may well look and work better than the old, which can lead to UI inconsistency, so it ends up being an exercise in inconsistency tolerance or management.

- Just gotta leverage tools to tell you more about the codebase than you might get from just looking at it (as in point 1) and do a lot of probably-boring and hard-to-measure difficult work. If it's still under development that means someone ought to be able to tell you what each largish part (feature, screen, section) should do, at least from the perspective of the end user, which may be useful. If no one can tell you that then why are you maintaining it, right?

Jumping off that fourth point: a great preventative measure for ending up in this position (or putting someone else there) is to make sure your code is written such that tools can more easily tell the reader facts about the project. Typescript over raw JS, that kind of thing. Static types are communication. They're communication that can be verified by a machine to be correct, more or less. They're great. Tests fail or pass. They tell you what the test writer expected to happen, and whether that's happening. They are communication. If all your comments get stripped and no-one updates the docs for two years and you get hit by a bus your types and tests still communicate. Even outdated test suites aren't totally useless. And static types pretty much can't go stale like docs or tests can.

[0] https://github.com/TrueFurby/go-callvis

[1] https://github.com/jamesmoriarty/call-graph (no endorsement, haven't used it, just an example.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#207

Post by YouKnowBetter »

My introduction was in BASIC (sinclair zx80), I started my profesional life as COBOL coder, in the meantime I reversed ASM to "unlock games".

I can asure you that in every step allong the way, the code (-base) I created horrified me 5 years later.

My point being: I appriciate the advice "throw it away and do it proper" but I can asure you, given enough time, the next person will not understand your solution.

Being it old languages, being it old paradigms, being it olt skool tricks of the trade: code stales. The best advice on this subject I read here (a couple of times) is to try to understand the requirements and take it from there. If that is not to your liking, you proberbly are in the wrong line of work and should try to do only greenfield stuff.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#208

Post by speedplane »

YouKnowBetter wrote: post #207

My introduction was in BASIC (sinclair zx80), I started my profesional life as COBOL coder, in the meantime I reversed ASM to "unlock games". I can asure you that in every step allong the way, the code (-base) I created horrified me 5 years later. My point being: I appriciate the advice "throw it away and do it proper" but I can asure you, given enough time, the next person will not understand your solution. Being it…

Can't agree more here. I can't tell you how many times I've heard, "this code is spaghetti, let's start over". I love clean architectures as much as anyone, but good developers are not afraid to jump into foreign spaghetti code, make precision cuts with a scalpel, and sew it all back up validated by robust automated tests. Drop the desire for simplicity; instead learn, embrace, and manage the complexity.

Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?

#209

Post by speedplane »

beaconstudios wrote: post #134
ConceptJunkie wrote: post #64

Earlier quoted context omitted.

I don't know about you, but I've rarely worked on a codebase that _wasn't_ awful in some way, and I am definitely not early in my career. I've come to the conclusion that most programmers are simply awful at their jobs, and the developers that can write clear, concise code are a small minority. I've known a few, but not many.

90% of developers think they're better than 90% of developers, but it's just an ego trip. Chances are, people have just had to compromise on design due to pressures from within the organisation. Or, as is often the case, they completed the exploratory coding phase of a new feature and the manager shipped it before they could refactor.

There are so many bad developers out there, I find this difficult to be true.
Post reply on HN