I have a bad habit of thinking it's bad when I just don't understand it yet. Acknowledging that bias makes it easier to spot and avoid.
Ask HN: Have you ever inherited a code base you thought was well done?
121–130 of 151 posts
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#122Earlier quoted context omitted.
Yeah that’s my current place. When I got there management didn’t even realize how bad the code was or that spending 70% of dev power on big fixes wasn’t acceptable.
I'm going through something similar. I recently scheduled a call with my engineering VP and highlighted the ratio of branches prepended with "hotfix" vs. "feature." It was a simple way to get their attention. With that perspective it's becomes fairly obvious there are some problems here that should be identified and addressed.
Sounds like it worked. My current place has basically done everything a guy could ask for (when given a nightmare codebase) so I no longer believe it’s always a systemic issue. My employers arent engineers and weren’t aware how poor their codebase was.
For any mid engineers who run away from spaghetti, I’ve learned identifying and solving that spaghetti problem can be a huge leap forward in your career towards management/leadership roles provided you find the right company and are able to solve the spaghetti issues.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#123One of my favorite good code bases, which I'd sometimes describe as being advanced technology that was gifted to us by outer space aliens...
I inherited a large code base in Scheme (Lisp) from two PhD engineering domain experts. One of them had been a systems programmer before grad school, and had built the foundation from scratch, including an entire complex Web backend and frontend framework, including continuation-based Web forms UI serving, and a versioned ORM with a meta layer (extensible by customer sites using an early browser-based Web UI builder), etc..
The system evolved for over a decade, with a very small and super-productive team, and was able to respond very rapidly to new requirements.
One more conventional Web example: when we needed to be in AWS, we owned and understood the underlying framework intimately, it had good abstraction layers where we needed it, we could code the protocols and understand the distributed systems changes, and just do it... which also got us the side honor of being the first system to get a particular federal security certification for AWS.
Another Web example: when we needed a handheld app, we were able to get into the guts of the meta layer, and do an HTML5 Offline app. A large part of which was generated dynamically, as a semantic translation of complex Web forms from the meta layer to idiomatic smartphone and tablet UI. (Admin user had previously painted a form with particular spatial layout with rich controls for knowledge capture in desktop and occasionally modified it, a new algorithm did structure recovery of grouping and ordering of those fields, mapped them to modern device-responsive handheld controls more usable on small touchscreens, and the system updated the generated app package for JIT updating as necessary.)
There were numerous other examples of how the code base evolved to growing functionality and operational requirements, but those two might be most recognizable.
Of course, part of it was the team and how we were managed. And part of it was that the code base gave the team a very smart head start with a powerful foundation that let it churn out functionality at a high rate early on, yet was also amenable to evolution with a very small team. I think these parts were complementary, and affected each other.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#124Earlier quoted context omitted.
I've been in the guts of about five Rails codebases that were already in production, and they've all been very bad, and the badness difficult to overcome in part because of Rails and/or Ruby (which is why I hang some of the blame on Rails itself). IME Rails codebases are a few months with a mediocre team or a few bad choices away from becoming an absolute garbage fire, and all the magic in Rails is part of why even a…
What about Rails causes this problem as opposed to other frameworks?
It's chiefly difficulty reading & navigating the code due to all the magic (made even worse by dynamic typing), plus reliance on extensive, comprehensive tests to maintain any amount of confidence it's doing what it's supposed to, or even to figure out what it's supposed to be doing. Not that tests aren't handy just about everywhere, but it's a matter of degree of reliance on them and how bad a time you'll have if the test suite's absent, or stale & neglected.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#125Earlier quoted context omitted.
> to survive long enough to be inherited by someone other than its original author. survival is far too low of a bar. We want delighted customers, low churn on employees, low minimum bar of required IQ to understand it (easier hiring, less stress), inexpensive modifications + improvements. Survival is only sufficient for cash strapped startups on borrowed time&money because if survival fails, then the future no longe…
>> soon as the future seems probable The next target then is acquisition or an IPO which is then followed up by quarterly earnings. It’s always survival first unfortunately
Yes, I agree survival is the bottom layer on the Corporate maslow's but what I'm pointing out is that a pure focus on survival in the ways that are common in tech companies these days (largely informed by cargo culting SV startups) actually will negate the possibility of future survival. Customer churn is more expensive than doing a feature well, no velocity on roadmap is death but also rapidly inevitable if pains aren't taken to ensure the code is "good code"
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#126Earlier quoted context omitted.
What about Rails causes this problem as opposed to other frameworks?
It's chiefly difficulty reading & navigating the code due to all the magic (made even worse by dynamic typing), plus reliance on extensive, comprehensive tests to maintain any amount of confidence it's doing what it's supposed to, or even to figure out what it's supposed to be doing. Not that tests aren't handy just about everywhere, but it's a matter of degree of reliance on them and how bad a time you'll have if th…
I'm sorry you had a bad time with Rails but I don't find this to be a fair assessment. I've done Rails development for about 15 years and worked on over a dozen production codebases.
> "all the magic"
The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.
> made even worse by dynamic typing
This is a feature Ruby shares with the #1 and #2 most used programming languages.
> how bad a time you'll have if the test suite's absent, or stale & neglected
I agree that having no tests or bad tests guarantees a bad time, but I'd say it's pretty standard for even the bad codebases to be covered pretty consistently with unit tests. The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#127I would argue that a lot of the time, people do not inherit a "bad" codebase. They inherit a codebase that successfully made enough of the right quality-vs-speed tradeoffs to survive long enough to be inherited by someone other than its original author. It's easy to spend a day with a codebase (that others spent years writing) and call it "bad". I'd argue it even feels pretty good to take that stance of superiority.…
> to survive long enough to be inherited by someone other than its original author. survival is far too low of a bar. We want delighted customers, low churn on employees, low minimum bar of required IQ to understand it (easier hiring, less stress), inexpensive modifications + improvements. Survival is only sufficient for cash strapped startups on borrowed time&money because if survival fails, then the future no longe…
>survival is far too low of a bar
Correct. I sometimes invite coworkers to partake in a thought experiment where they anthropomorphize the company (and/or codebase) they work at imagining, if it were a person, what state of health would it be in? This usually engenders a chuckle or two of some sort as they picture someone whom, though they are surviving, is otherwise in seriously poor health and does well to illustrate to them that if they were this individual they would likely be striving to significantly improve their quality of life and not just merely maintain status-quo of still having a pulse being the measure of success.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#128Earlier quoted context omitted.
It's chiefly difficulty reading & navigating the code due to all the magic (made even worse by dynamic typing), plus reliance on extensive, comprehensive tests to maintain any amount of confidence it's doing what it's supposed to, or even to figure out what it's supposed to be doing. Not that tests aren't handy just about everywhere, but it's a matter of degree of reliance on them and how bad a time you'll have if th…
I'm sorry you had a bad time with Rails but I don't find this to be a fair assessment. I've done Rails development for about 15 years and worked on over a dozen production codebases. > "all the magic" The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere. > mad…
> The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.
Noooooo. A ton of things simply aren't defined until the program's running. "What even is this?" is frequently a question that's hard to answer without running the project (hope it's in a runnable state, then!)—even figuring out whether something's from Rails or from some other module (which one? Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain. There's far less runtime metaprogramming magic in any other ecosystem I've worked in, which is lots and lots of them (including iOS). It's everywhere in Rails.
[EDIT] Also:
> The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.
Yes, tests are good! A culture of testing is good! But not every language/framework suffers so greatly from absent or bad tests as Rails does. Such heavy dependence on them is not a strength of Rails (though the culture of testing is).
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#129Not someone else's code but I had the strange experience recently of revisiting an old project of mine (DNS server written in typescript + deno) and being intimidated by the quality of my own code . I had those familiar feelings of "I could never write code like this" or "I'd never have thought to do it like that!" or "This person must really know their shit". Turns out it was me all along and I'd just forgotten I'd…
I've had that experience. I honestly sometimes worry I've peaked and am getting less good at figuring out how to compose good code as my brain ages. I think I'm actually getting better at it, at least in some ways... but not totally sure there aren't others I'm not quite as brilliant.
if age is greater then mid-30s then yes, else no.
Re: Ask HN: Have you ever inherited a code base you thought was well done?
#130Earlier quoted context omitted.
I'm sorry you had a bad time with Rails but I don't find this to be a fair assessment. I've done Rails development for about 15 years and worked on over a dozen production codebases. > "all the magic" The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere. > mad…
> The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere. Noooooo. A ton of things simply aren't defined until the program's running. "What even is this?" is frequently a question that's hard to answer without running the project (hope it's in a runnable state,…
> Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain
Funny, none of those things sound bad to me, but just like part of the job :D Could be Stockholm Syndrome?