Live data from Hacker News

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

news.ycombinator.com

141–150 of 222 posts

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

#141
post #123
post #100

I know of a very popular London startup who's entire database is in Spanish due to the initial dev work being outsourced to a development company in Spain. All table, column, and procedure names are in Spanish. A refactor is too risky and they are growing too fast, so all the engineers have to pick up basic... programmer Spanish? That's a more literal example of not being able to understand the codebase I guess.

I'm spanish and loathe spanish-written code. It looks so unprofessional to the eye. Luckily in all spanish companies I've worked on they had an english-only policy for the code and comments. This was because the companies didn't discard that foregin devs could join at some point in the future and friction should not come from a lack of Spanish skills when reading /writing code. It made however for some funny comments…

At my company we're finally trying to write code in English (much to the despair of way more developers than I would have expected), but one serious difficulty we've encountered (appart from people that don't know how to write correct sentences...) is translating domain-specific terms. Either it seems like bad translation, or it's not understandable at all.

I don't know what the solution should be in that case? Keep domain-specific terms in French?

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

#142
The company's entire code base was split into two: Java from the 'enterprise' stuff, and Perl for everything else. The Java side had something close to 20 million lines of code, and the Perl side had about one million lines of code. As always, I worked on the operational side.

NB: I rather like Perl, though I haven't used it much at work since leaving this company a few years ago. The ...things that follow are not an indictment against Perl. The problem wasn't the language.

Even used properly, Perl is a pretty dense language, so a million lines of Perl in one place is quite impressive.

The company's code started in the mid 90s and continued to grow. When I arrived, there were a couple of guys on the operations tools team with me that had been there 7-9 years I believe. They understood the code better than anybody, and they were both very bright guys, but things came up, at least a couple of times a week, that would surprise and sometimes mystify them. After some digging, debugging and sniffing around, they'd usually approximately get somewhat near a root understanding.

That's fairly amazing to me. I've helped create some enormous code bases my decades long career, in one case, even larger than a million lines. And I'd certainly find myself surprised from time to time, but never for very long.

So these millions of lines of code had, over the prior 17 years, grown organically, and had, essentially, never been refactored.

The code itself was, for the most part, quite tidy. And the underlying concepts and structures were pretty simple and elegant. They represented approaches I mostly agreed with.

But...almost nothing had ever been removed. No refactors, over millions of lines of code, over most of 20 years.

There were side effects everywhere. Many of the deep, underlying methods had had so many arguments added that perhaps one third them would be useful or used in any given invocation.

And, of course, there were virtually no tests.

After somewhat getting up to speed on this system, I declared it DOA, and started to push for a complete rewrite. I've been around the block enough times to understand and comprehend the hazards of that approach, and I didn't mentally pull that trigger lightly or quickly.

But....the organization would not have it. The two senior guys on my team were fine with the idea, but many other long-timers were not.

That code is, to this day, with no doubt another 100k lines of Perl added to it, (poorly) powering fundamental and important pieces of a huge company you have all heard of.

So management basically threw bodies at it. Lots of bodies. And, even though the operational quality of the products were objectively fairly poor, the particular market niche didn't need or demand better, so the company made and continues to make a ton of money.

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

#143

I beat it like it stole something from my mother. I write comments read it over and over and make changes where possible. I stay glued to it like it is my new found bible and become a guru of the code base through blood, sweat, and tears. It is the only way to handle new code not to hate it, not to blame others, and not think you could have done better. You befriend it accept it as it is and move forward with the bes…

This is the attitude man. I love huge legacy codebases, dive in and get dirty.

This is the job, just shut up and get on with it.

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

#144
post #100

I know of a very popular London startup who's entire database is in Spanish due to the initial dev work being outsourced to a development company in Spain. All table, column, and procedure names are in Spanish. A refactor is too risky and they are growing too fast, so all the engineers have to pick up basic... programmer Spanish? That's a more literal example of not being able to understand the codebase I guess.

I had something similar with German. The company paid for us all to have German lessons which was nice.

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

#145
post #89

Earlier quoted context omitted.

Exactly. Everyone thinks that the predecessor is an idiot and they can do it better. Every time you throw away existing code you lose business knowledge.

I agree with you in general, but I think a better rule would be to almost never rewrite code. I know that everyone thinks their predecessor was an idiot. And I agree that full rewrites are usually a bad idea. But sometimes, the predecessor genuinely was an idiot, and the code really is that bad. If the use cases and inputs and desired outputs are well documented enough, a full rewrite can be the right choice. It depe…

If the inputs and outputs and the use cases are understood and it’s akready working, create an anti corruption layer and treat it like a 3rd party binary blob.

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

#146

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…

I think badmouthing the developer who came before you is not good. But, a long succession of good developers, can jointly produce a codebase which is awful. Part of this is simply the fact that it has changed hands many times. Part of it is decisions made that the developers were not able to control. There are many other possible reasons. But, although most developers are trying to do a good job, and I think it is bad form to badmouth the developer before you, it is often quite simply the case that a large and old codebase is, in fact, truly awful.

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

#147
Lots of good stories. How to decide, rewrite or maintain?

I liken maintaining large, old, arcane code to the care and feeding of a dinosaur. Maybe a Brotosaurus. It's sitting there cropping the treetops happily, farting occasionally.

You want it to do something else, you have to poke it, prod it, yell at it and it slowly gets up and takes three steps. Then it sits down again.

You'll never get very far that way, and it'll never do much more than it does. If that's cool, ok. If not, then its time to consider another approach.

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

#148

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…

Do they not make Virtual Machines where you come from? Or am I missing something?

Well no, that particular office didn't. The office I was a part of did. Suffice to say their DevOps-fu was slightly weak compared to the rest of the organization.

I was the one who actually set out to build the VM image.

Not a trivial task at all to get the VB6 side of it running. Which is the exact reason we are supposed to do things like making VMs for development environments.

It would be nice to be at all places in all points of time with perfect knowledge in order to stop bullshit from happening in the first place but I can only be here and now.

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

#149

That is essentially what I was hired out of school to do. I walked into a massive heap of ASP.NET (with VB) and MSSQL stored procedures that didn't really work at all, and had been through the wringer of a few cut-rate outsourcing groups. I struggled along with it for a few months figuring out how it was supposed to work and trying to duck-tape it together, doing a lot of support with customers that were trying to us…

If you can rewrite it in 3 or 4 weekends, it's really not that complicated. Either that or significant chunks of it were retained and your improvements were mostly cosmetic.

It really wasn't very complicated... basically just some queries to search a database and a front-end to display results.

I still don't know how the preceding mess got to the point of being such a baroque cobbled-together monstrosity, but it was enough copy-pasta to keep an Olive Garden supplied for a year, and a raft of incomprehensible stored procedures that did SELECT * FROM table WHERE xyz in bizarrely complicated ways involving multiple casts and nested temp results.

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

#150

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…

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.

I've also rarely worked on a codebase that wasn't awful in some way, and I've come to the conclusion that maintaining best practices across a sprawling codebase is really hard.
Post reply on HN