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

151–160 of 222 posts

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

#151

Post by PhasmaFelis »

orf wrote: 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.

In the mid-2000s, I inherited a code base that was supposed to recommend nearby points of interest (coffee shop! pizza place!) based on your zip code. It had been written by a contract programmer in India who naturally didn't understand how US zip codes worked. That was interesting.

(He also didn't understand how functions worked, but that's another matter...)

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

#152

Post by spc476 »

linuxlizard wrote: post #63
hackernews31242 wrote: post #10

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…

Do you have any specialized tools (code navigation tools, for example) that you use when first encountering these large piles of code? I'd love to hear some recommendations; I have to deal with large (only sometimes bad, but always large) piles of vendor code. I'm currently staring a pile of 900kloc of pretty nice code but it's a /lot/ of code.

It depends upon the platform, the language and the toolsets. For instance, for C, a trick I've used is to (if I can) use different C compilers and crank the warnings/errors to 11 and fix every complaint (or try to---it can be daunting to attempt this all at once).

Other tricks---run the code through linters or other stylistic nit-pickers and fix those too. I haven't yet used a code reformatter, but that's a quick way to get code into a consistent style.

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

#153

Post by Jach »

moltar wrote: post #31

Yes, it was a mega legacy codebase written by a single person over the span of a decade and was extremely “job secured”. It had Perl scripts that would system call to php scripts that would in turn do a curl request to another http perl script that would system call another php script that would output HTML, which then would get parsed by the calling scripts several ways. That was just one place. There were lots and…

Would love to know what happened once you were done, especially was the original developer still around and did they have a funny panic mode upon realizing the job security rug had been pulled out from under them?

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

#154

Post by Kalium »

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…

> But sometimes it is good old fashioned workplace politics. It is risky to take on an unfamiliar codebase as any problems are now your problems in the eyes of management. And it is, practically speaking, impossible to account for all edge cases and surprises that may exist in a legacy codebase.

When I was a more junior engineer, I thought I would be appreciated as helpful when I demonstrated that I could figure out and become productive in a new and umfamiliar codebase quickly. This was indeed the case! For a while, at least.

Over time, exactly what you predict set in. I was expected to account for all possible surprises in legacy code. In addition to being handed more tasks in legacy code, I was also expected to account for all edge cases and surprises in there. Being able to blame the previous developers, believed by management to be excellent and highly competent, would have saved me a lot of grief.

Perhaps unsurprisingly, this did not exactly thrill me and lead to wonderful performance on the job.

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

#155

Post by arp242 »

hadrien01 wrote: post #141
j1elo wrote: post #123

Earlier quoted context omitted.

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…

I've also ran in to the reverse problem: mixing English and Dutch in confusing ways. For example, a common naming pattern in is `GetFooByID()`, `GetFooByName()`, etc. I think it makes sense to stick to that, but if `Foo` is a non-English word it just gets confusing/inconsistent, especially because in some cases you would translate Foo and other cases you don't.

On the other hand, translating domain-specific terms can also be very confusing. For example at my previous position we built a rental contract system that was very specific to the Dutch rental system/laws. We translated everything to English, but a lot of stuff is just funky because it's a specific Dutch term without a real English translation (for example names of specific laws/procedures).

My advice is to give up, destroy your code base, and become a sheep herder. You're screwed no matter what.

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

#156

Post by taurath »

koala_man wrote: post #66
EpicEng wrote: post #52

I was hired for this exact reason at my last company and tasked with rewriting it while maintaining bit-for-bit identical output. The company itself was in biotech (cancer diagnostics) and was relatively new, spun off from a rather well known research lab. They quickly realized that their system was incapable of scaling (or being maintained properly...) to the needs of a business. The code itself was written primaril…

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

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

#157

Post by jack-facts »

james_s_tayler wrote: post #35

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.

It was kind of sad everyone came in trying their best to improve the software and environment, but they were quickly shot down by their boss. If you didn't copy paste his code you'd get a snarky email a few days later about not following the guidelines, that were never written down mind you.

My lesson for rewriting a legacy application, have the right management in place. If there is an old dev that does not want to change, the project is a waste of time and money, he'll have more sway over the executive team and often get his way.

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

#158

Post by swerveonem »

ashrk wrote: post #88
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…

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…

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

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

#159

Post by EpicEng »

Balgair wrote: post #110
EpicEng wrote: post #99

Earlier quoted context omitted.

I stayed until I finished it. It wasn't a rwrite anymore, only the application stayed the same, and even then we added a ton of functionality (e.g. morphological analysis as well as identification.) It's something I wanted to complete as I literally built huge parts of it by myself and wanted it to succeed. I took what I learned at the previous company and had a chance to build something similar from the ground up un…

Can you recommend any good biotech companies in image/optics? I just got my degree in BioEng. in bio-optics and have been pretty unsuccessful in getting any traction on the job market.

I was involved in the digital pathology sector. Leica (formerly Aperio) has an office in Vista and I hear it's still a good place to work after the acquisition. You may also try Epic Sciences, indica labs, or BioImagine. There are far more, but you could also try going to local conferences. I used to attend pathology Visions each year. Lots of industry representation and new tech.

You probably know this already, bit look for assay dev labs with existing software groups. Best of both worlds. Otherwise you run the risk of developing software in a culture which inderstands nothing of software dev. Not fun.

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

#160

Post by EpicEng »

tndoan wrote: post #124
EpicEng wrote: post #52

I was hired for this exact reason at my last company and tasked with rewriting it while maintaining bit-for-bit identical output. The company itself was in biotech (cancer diagnostics) and was relatively new, spun off from a rather well known research lab. They quickly realized that their system was incapable of scaling (or being maintained properly...) to the needs of a business. The code itself was written primaril…

I think research world has a lot of this kind of code. These projects are written by 1 or 2 and it is extremely hard to understand what really is under the hood.

It does, can confirm. I've rewritten more than a few MATLAB algorithms which, while novel, were of... questionable... quality.
Post reply on HN