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

181–190 of 222 posts

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

#181

Post by kjeetgill »

hackernews31242 wrote: post #175
cm2012 wrote: post #174

Earlier quoted context omitted.

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.

Sorry, to clarify: I meant a means to contact you, not your prospects. I was just curious about your business and didn't mean to be intrusive.

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

#182

Post by james_s_tayler »

celdon25 wrote: post #131
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…

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

Yeah my biggest red flag is people who fail to have a proper discussion about what color the sky actually is.

Unfortunately people often aren't incentivized to discuss the actual color of the sky,but rather the color as either they would like to see it or that would suit their agenda the best.

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

#183

Post by aryehof »

Certainly. One could consider that any large team complex system that has functional requirements determined (and best understood) by external domain experts, is likely not understandable by software developers. This is exacerbated by our industry having no standard way to map those complex requirements into executable code.

The result is likely some big ball of mud, partially understood by the (now gone) original developers. One that is hacked at and refactored at the edges by those who inherit it.

Consider an actuarial risk calculation model, a payroll system, an air traffic control system, or perhaps something simpler like a model of a double-entry accounting general ledger. Could you wholistically understand the code base of a double-entry accounting solution?

Such large complex systems cannot normally be rewritten economically prima facie. Instead if possible, typically small parts are carved off, rewritten and delegated to, until the economics and inability to add new features absolutely force some attempt at a rewrite.

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

#184

Post by naikrovek »

rdiddly wrote: post #50

I did - please bear witness while I work through my trauma. Variable names were actively obfuscatory, and their declarations were always many hundreds of lines distant from their use. And many weren't even used at all. Or some were assigned values that never got read or used for any purpose. In a language that generously provides many useful data types, booleans were being converted to strings so he could check wheth…

Code that can't be quickly replaced is a liability, in my mind.

Your example is an extreme case, and I think that even in non-extreme cases, code that has inertia is bad. The inertia is just not AS bad as the inertia in your story.

If you can't, (as an example,) wrap your mind around a codebase that implements a bit of business logic, in a day, that code is too complex. It should be replaced with something that can be understood quickly, and changed quickly, when the person who maintains it today, dies, retires, or goes on vacation.

(In the above, substitute "day" for whatever period is suitable for your situation, and "person" for whatever employee-unit is suitable for your situation; "lead dev", "team", whatever.)

Software has more inertia than hardware, and that is INSANE. There is software at my employer that is OLDER THAN THE FUCKING X86 ARCHITECTURE, and has gone untouched for much of that time.

"If it works, why touch it?"

A business needs to understand what is running (for legal and other reasons) and needs to be able to fix it, change it, or replace it very quickly, because if it is implementing a business process, it is important for business, and if it is important for business, then it needs to be able to adapt as the business adapts.

Some things change very little, true; that doesn't mean everyone who worked on it should be allowed to retire, then rehired as contractors 20 years later when the mainframe hardware finally goes out of support.

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

#185

Post by j1elo »

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'd say if it's a country-specific thing with domain terms that one would need to learn and know anyway to do the work, even if the programmer was foreigner... then keep those terms without translation. It will be less confusing.

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

#186

Post by informatimago »

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…

I agree that unfamiliarity should not awful a code base make.

However, there are degrees, and probably thresholds. If your code to manage web site users is using string theory, despite the assumedly concise, elegant and refined code, it would make it awful to all programmers, but the two in the world who master both programming, web site user management and string theory.

Otherwise, bad design patterns and bad coding practices definitely characterize awful code bases.

But the worst, is when it’s so bad that you can hardly refactorize it.

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

#187

Post by informatimago »

ConceptJunkie wrote: post #64
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…

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.

Obviously. For 70 years now, the number of programmers has been doubling every 5 years. In consequence, on averge, half the programmers have less than 5 years of experience. Therefore almost all the code will be produced in a awful way, using awful new reinvented programming language-du-jour, and new reinvented configuration-and-build-system-du-jour.

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

#188

Post by informatimago »

j1elo wrote: post #123
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.

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…

Using national language in code bases is indeed bad, if you want tomhave them sold to foreign companies or contributed to by the international community. On the other hand, it may be good if you want to avoid this. I guess, not a lot of the sources developped in China is hacked on by non-chinese, or easily spied on by foreign powers...

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

#189

Post by informatimago »

elevation wrote: post #23

Rafactor, test, repeat. I contracted for a company that had no software team, and had outsourced the development of their embedded product to the lowest bidder. The original firm had delivered code that met most requirements, but were not willing/able to resolve issues with random crashes or implement additional features. The product manager reached out to my employer at the time for help. When I took over the code b…

Well, if the code base is awful, it won’t have test to begin with... what do you test when you only have the bad code, no doc, no specs...

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

#190

Post by MichaelMoser123 »

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…

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 using some container mechanism, like spring, etc) Do you manage to reduce said numbers of indirection without breaking things?

- microservices like to do that a lot (going through n levels of services just to get to the target server - with different languages and RPC protocols involved). I had once spent a week to add a frigging attribute. Any tips here?

- gui code often turns into a mess (like when it takes it short of a week to add a frigging detail); how do you deal with that?

- how do you deal with the problem of missing context? (when trying to read through the source and there is nobody there to explain any rational of what is going on?) (for me knowledge of other systems often helps to bridge the gap, are there any more empirical approaches?)

For me these things are hard, though i manage (sort of). How do you do?

Post reply on HN