Live data from Hacker News

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

news.ycombinator.com

171–180 of 222 posts

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

#171
Earlier in my career. I've noticed the more years I've been developing software, the easier it is for me to understand other people's code.

Also, when I see a codebase I don't understand, if I'm paid to work with it, I spend my time learning the stuff. Debugging tools help: traditional general-purpose debuggers, graphics debuggers like pix/renderdoc, network tools like wireshark/fiddler, OS-based tools like strace/procmon. For different projects different ones are the most useful, sometimes even custom built tools are most useful.

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

#172

Earlier quoted context omitted.

>maintaining bit-for-bit identical output The worst projects are those when the company doesn't really want to upgrade, so the only requirement is "make it exactly like the old system" In my first job out of college, I upgraded an approval workflow engine from VB3 to C#. It was written by someone who had never heard of state machines, so it had a weird ad-hoc design that would e.g. get confused if two documents were…

If those calculations are business rules, then you absolutely do need to make it output the same as the old system in those ways because its the foundation upon which a bunch of assumptions are made.

They were primarily intermediate values used in the overall process of finding a certain type of cell. The algorithm needed improving anyway in order to be production ready, so in this case identical output was not necessary.

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

#173
Got handed a code base that had been slapped together by an offshore dev shop. It was a spaghetti combo of c, php, and Java. The configuration data was located inside a compiled c binary provided to us by the dev shop. If we wanted to make a config change we had to ask them to do it and send us a new binary. Kind of awkward since they had been fired due to slipped deadlines and horribly buggy code (insert shocked face here). We scrapped the whole thing eventually. I'm still blown away by how bad it was. Never seen anything like it before or since.

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

#174
post #92

Earlier quoted context omitted.

Huh, I love working on a untangling and managing large old codebases. Mind sharing where your company or contacts?

Same - send us some info so we can do this too.

I'm not OP, but I would be turned off by this comment because it sounds demanding.

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

#175
post #174
post #92

Earlier quoted context omitted.

Same - send us some info so we can do this too.

I'm not OP, but I would be turned off by this comment because it sounds demanding.

Yeah bit of an odd request for me to send you my business contacts. It really is being in an industry long enough to build a reputation to get things done. And these are enterprise projects, there’s no sexiness here. This is webforms in .NET type of stuff. Learning to ignore that the codebase is imperfect and will never be reasonable is one of the reasons I get calls.

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

#176
Thanks for the responses everyone! Definitely some entertaining stories here. Don't worry, I wasn't thinking of rewriting one, just wondering aloud how often this happens, and it sounds like a lot :) Really cool to hear from those of you who deal with this all the time. Thanks for the great reads.

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

#177
post #120

No. I have inherited code that is very difficult to understand, though. What typically happens is that it is mostly left alone. As the years go by, small changes are be made, only making the situation worse. Developers occasionally offer to management to take the time to refactor it, but management refuses to prioritize that work. Eventually, new requirements are drafted that the existing code simply cannot meet with…

Interesting that this is the conclusion you've come to, because I've heard from some colleagues that this is actually the correct approach for management to take. Their argument would be that either way, to accommodate the new functionality, the codebase would have to be refactored. And if it is refactored proactively, well that will probably be in a way not compatible with the future design, because you can't anticipate something you know nothing about.

So it's a matter of 1 vs 2 refactors, and the management chose one by delaying as long as possible.

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

#178

I’m a consultant and make a living saving bad projects. That’s literally why I get phone calls for work. Keep in mind that I work in high level modern languages, I’m sure there’s some crazy proprietary cpu running a robot in a Detroit factory. In any case there’s never been something that I’ve run into that I’ve not figured out. It takes time, and the hard part usually is not figuring out what it does but the weird e…

That's really interesting, and definitely agree knowing the requirements is hugely important. I've heard from people at BigCorps about inheriting projects where no one at the company really knows how or why a piece of code behaves the way it does. That seems like one of the more terrifying scenarios, where you can't even ask someone what a particular piece of code is supposed to do, and you have no way of knowing how it's supposed to work (and then you are tasked with fixing bugs when they crop up). But I guess those three conditions are unlikely to overlap probably (hopefully).

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

#179

I once inherited a large enterprise system I had to build a full working development environment for and then learn the code base and help bring a team up to speed. The product was essentially made up of 5 code bases in a single repo that built and deployed 5 different executables that worked together. That itself wasn't so bad, it was mostly modern C# and I found it a decent code base to work on. What was bad was th…

Ha, I just left a job that had multiple VB6 apps and services that we were actively maintaining and extending. Getting the development environment setup wasn't too bad. What drove me bat shit crazy, was the fact that the mouse scroll wheel isn't supported in the IDE. I was part of the third team that left in as many years. Just another lesson of a single individual being the only decision maker across all departments…

On all accounts mentioned that sounds like the ultimate torture.

I legitimately can't work out if such an intolerable boss is more painful or the constant need to scroll the IDE and having to do it without the mousewheel.

I feel for you. I truly do.

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

#180
post #164

Earlier quoted context omitted.

Being able to solve those problems like "it ain't no thing" is part of being a senior developer.

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…

"Unless you like trash fires, which some people do."

I'm dying.

Post reply on HN