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

131–140 of 222 posts

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

#131

Post by celdon25 »

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 if a developer says the sky is blue? Maybe you're the red flag in that case?

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

#132

Post by ericb »

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…

> we'll move it to jruby!

Hahahah Oh man, that's great. BTW, we had people who did this. Our performance is 2x better with half the servers after we undid this "optimization" at our org. I suggest benchmarking first.

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

#133

Post by [deleted] »

sidlls wrote: post #125
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…

Generally I agree, but there certainly are exceptions. When it's a code base "nobody" can understand and that no other team or developer wants to maintain because of its complexity or infamously poor prospect for maintenance, that's a sign of a poor codebase.

[deleted]

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

#134

Post by beaconstudios »

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.

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.

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

#135

Post by darkr »

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…

Oh I inherited a similar Perl/php/shell script mess a few years ago. A fun twist was that the codebase started off as a commercial groovy/grails application, and had this Frankenstein thing surgically attached, reading and writing to the same database tables.

Still have nightmares about it now.

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

#136

Post by ams6110 »

thrower123 wrote: post #13

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.

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

#137

Post by smilesnd »

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 best you got.

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

#138

Post by rzzzt »

osrec wrote: post #129
zem wrote: post #128

Earlier quoted context omitted.

"After me cometh a Builder. Tell him, I too have known." http://www.kiplingsociety.co.uk/poems_palace.htm

In a nutshell: people who make stuff are critical of other people who make similar stuff :P

People who repair stuff (or people) are even more critical of the repair work done by their peers.

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

#139

Post by jghn »

Yes. What’s worse is that it didn’t work as it was supposed to.after a lot of effort later we realized that the last remaining developer who had just left was manually fudging things in the database instead of patching the code.

It requires going back to first principles: digging into the docs on the systems it interacted with, interviewing users to see what they did and what they expected, in short a nightmare

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

#140

Post by JoeAltmaier »

ams6110 wrote: post #136
thrower123 wrote: post #13

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.

Or, they are actually good at their craft and rewrote it. That's not an unreasonable timeline. Taking code that does something and writing another version in another design pattern is much, much faster than starting from scratch. Even with complicated code (especially with complicated code)
Post reply on HN