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

161–170 of 222 posts

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

#161

Post by jehlakj »

manicdee wrote: post #116
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…

Yeah nah. We don’t describe code as “awful” because we truly want to rewrite from scratch. Code can be quite awful simply because a company has a high developer turnover due to hiring practices (you can code? Good, write our payroll system) and management (the bearings will continue until morale improves). As a result you end up with every function using different nomenclature, different approaches to encapsulation,…

Agreed. It's impractical to incorporate "ideal patterns and practices", but competent developers can get pretty close.

Having said that, I much prefer working with code that is very simple and redundant with a verbose API, than with a codebase that is overly refactored and abstracted.

Finding the balance of the two extremes would be my definition of an ideal pattern.

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

#162

Post by jehlakj »

jeffwass wrote: post #115
maxxxxx wrote: post #91

Earlier quoted context omitted.

Especially in big companies it's really hard to keep your code concise. I have often started with a very clean design that totally feel apart when new requirements came in. If you give managers the choice to hack it into the code in 1x time or redesign the code in 2x time most of them will vote for the first option. Go through that cycle a few times and your code will be a big mess

This 100%. I’ve worked on several codebases over the years where a mgr said “here’s a special case, inputs of (foo, bar) should give baz2 not baz1. Coder whips up a hacky workaround to that very specific ask in the simplest place possible, not the right place. A few dozen requests come in like this over the months. Overrides and exceptions are now scattered all over the code base, without any semblance of order, func…

It's hard to blame them. I've been in similar situations multiple times where a requirement seems simple enough on the surface that you only get a few hours to work on it. But it's actually not that easy to write it cleanly.

That hacky workaround you're talking about? Well, my task depends on it. The workaround too depends on another hack. With the amount of time I have to work on it, it's a no brainer.

Earlier in my career, I tried to fix them, but they started to break other "hacks" and down the rabbit hole I go. Sometimes it's just not worth it.

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

#163

Post by jehlakj »

osrec wrote: post #122

Yes, most of it. Most (all?) code in a pressurised business environment eventually ends up in a bit of a bad state because technical perfection and maintainability are rarely what the devs are going for. They're just trying to "get it working, and now". How I've seen devs deal with it successfully: 1) Complain early and loudly about past mistakes from other devs, so that management know delays are not your fault. Onc…

That was my mistake when I first started. The manager didn't think it would take too long to finish a task. Well, the naive me, without even looking closely at the code, didn't think it would either.

But I realized the more I understood, the more dependencies needed to be changed. While it's still doable, things started to break and I ended up learning way more about the project than what was required to finish the task. In the end, it took me longer to finish it.

The fact that most of my coworkers would write a hacky solution in a short time, it made me feel incompetent. Managers without a technical background don't look at code, they look at results. So how do you even do #1 when the "other devs" still work there and can get stuff done much quicker?

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

#164

Post by ashrk »

swerveonem wrote: post #158
ashrk wrote: post #88

Earlier quoted context omitted.

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.

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 greenhorns, though often they're given comical levels of responsibility (typically by the cash-strapped or cheapskates) resulting in some real messes, which has a similar effect to when an incompetent "lead architect" or an experienced team nonetheless without a clue between them is set loose, which is just as common.

I harbor no ill will toward these folks. Hell, selfishly, I'm glad there are so many. Having half an idea what you're doing is guilt-inducingly easy, pays amazingly well—especially after the confidence-boost and resulting swagger and negotiating attitude that comes with seeing this kind of thing over, and over, and over, for years on end—and it's disturbingly easy to be a or the "smart one" in the room when you're kind of a dummy, in fact.

[0] Dear backend devs: if you don't simply love backend work and/or if you aren't very well appreciated compensation-wise, and especially if you have long-term career aspirations that involve shifting more toward the biz/architect/management side for the extra social status and higher late-career pay (in most of the industry outside the huge West-coast tech companies, anyway), consider moving to more high-visibility pastures—though ideally not web frontend, as, incredibly, it's still a trash fire and comp is so-so, mostly. Unless you just like trash fires, which some people do.

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

#166

Post by jiveturkey »

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…

most really are that bad. try this on for size: look at your own code from 4 years ago.

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

#167

Post by lostctown »

jehlakj wrote: post #163
osrec wrote: post #122

Yes, most of it. Most (all?) code in a pressurised business environment eventually ends up in a bit of a bad state because technical perfection and maintainability are rarely what the devs are going for. They're just trying to "get it working, and now". How I've seen devs deal with it successfully: 1) Complain early and loudly about past mistakes from other devs, so that management know delays are not your fault. Onc…

That was my mistake when I first started. The manager didn't think it would take too long to finish a task. Well, the naive me, without even looking closely at the code, didn't think it would either. But I realized the more I understood, the more dependencies needed to be changed. While it's still doable, things started to break and I ended up learning way more about the project than what was required to finish the t…

The sad truth is that in order to bear the cost of a long time horizon in the pursuit of elegance you need one of two things: extreme trust or total control. Even then the pursuit may lead you astray and ultimately result in failure. Until there are ways to transfer experiences from one mind to another in an efficient manner, few manager/higher ups will sympathize with a desire to take on more long range, highly technical code improvements (assuming we're not talking about a FAANG).

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

#168

Post by flukus »

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.

I've worked on similar projects that could have been re-written relatively quickly but were only complicated because the developers made it complicated. Some devs just want to solve hard problems in "elegant" ways and will throw in elaborate inheritance chains, meta-programming, code generation, service oriented architectures, layers upon layers, frameworks, rules engines and anything else that's not boring business logic.

IME these projects are usually more complicated than all but the most wild of business logic.

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

#169

Post by wingerlang »

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…

My bother worked in this situation, they kept the domain specific words in the local language because translating would be difficult.

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

#170

Post by andrewf »

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.

Is it useful to calibrate the software scale in a way that concludes the majority of codebases are "awful" ?

What are we usefully communicating with the word, if 90% of codebases qualify?

Maybe software development is hard, sometimes unpleasant enough, to justify the crazy salaries, and the endless complaining about every codebase more than 2 years old is not quite justified..

As a collective group, software devs are really prone to self-flagellating while they go about delivering billions of dollars in value.

Post reply on HN