Mistakes engineers make in large established codebases • Hacker News Board

Re: Mistakes engineers make in large established codebases

#361

Post by AndyNemmity » Thu, Jan 09, 2025, 7:48 PM UTC

jongjong wrote: post #144

AndyNemmity wrote: post #90

Earlier quoted context omitted.

Only 3 days? That's incredible. Getting a PR reviewed in 3 days is an achievement!

Not sure if you're serious. I can't remember working for any company that took more than a day to review a PR. I think this company took about 1 day to provide QA feedback and I was thinking that it's so slow. In startup land, I got my code reviewed by the CTO within a few hours. It was rare if it required a whole day like if he was too busy. In my current company, the other dev usually reviews and merges my code to…

I was definitely serious.

Re: Mistakes engineers make in large established codebases

#362

Post by RaftPeople » Thu, Jan 09, 2025, 8:21 PM UTC

david-gpu wrote: post #273

bluGill wrote: post #264

Earlier quoted context omitted.

I was involved with a big rewrite. Our manager had on his desk the old system with a sign "[managers name]'s product owner". Nearly every time someone wanted to know how to do something the answer was load that old thing up and figure out what it did. Eventually we did retire the old system - while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place. It still…

> while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working. I was also told about an earlier big rewrite of a similar codebase which was a multi-year disaster that was eventually thrown away completely. I did see one big rewrite that was successful, but in this case the ne…

> I saw one big rewrite from scratch. It was a multi-year disaster, but ended up working.

90% of large software system replacements/rewrites are disasters. The size and complexity of the task is rarely well understood.

The number of people that have the proper experience to guide something like that to success is relatively small because they happen relatively rarely.

Re: Mistakes engineers make in large established codebases

#363

Post by lmm » Fri, Jan 10, 2025, 3:54 AM UTC

edanm wrote: post #346

lmm wrote: post #344

Earlier quoted context omitted.

> I think this misunderstands how the companies that have stayed in business for so long have done so. Excel is the software we all use every day because it kept adding more and more features, stealing the best ideas from new products that tried to innovate. Not convinced. I think a lot of companies keep adding features because they don't know how to do anything else - adding new features is how managers get promoted…

Yes, I understand the sentiment and am familiar with this argument. And sometimes it's totally true! But I'm pushing back because I think it's sometimes not true, and that this is more an "anti-growth" or "here's-how-real-devs-work" talking point that is sometimes applied incorrectly. E.g. how far are you taking this? Excel was released in 1985. Do you think after 5 years there was no more business value? VBA, allowi…

You're talking about a couple of general, powerful features, which is exactly the kind of thing that doesn't take 5 million lines of code to implement. Collaborative editing is definitely worthwhile. Integrating a scripting language is probably worthwhile. The only way you get to a huge ball of mud codebase (other than by being bad at programming) is by having lots of things that really are isolated special cases like, IDK, one more obscure statistical distribution that you can sample from, or one more date format, or one more connector integration.

Do important general features start out looking like this kind of esoteric edge case? I don't think so, though I'm not hugely confident. I think it should've been clear in 2005 that enabling collaborative editing would have been a fundamental shift that required reworking the core of Excel, not something that a single internal team could add as a checkbox feature. I think that's probably part of why it didn't happen.

There's definitely some business value from "supports everything", and in a messy human world that can be very complex - just things like knowing the business day calendar for every country take space in code, and if you're writing a piece of software that commits to integrating with everything else then the number of integrations you have to write is more a function of politics than of engineering. But I think that part is very much on the long tail, the "last 20%".

To answer the specific question, yes, I do think Excel 2000 is as good as Excel today is. I honestly can't think of a single positive new feature (automatically suggesting tables seems cool, but I don't trust it), and the changes I did notice are mainly the ones that got in my way like the "ribbon" menu. I'm sure some businesses are getting some extra value out of today's Excel, but only in long-tail stuff.

I don't blame people for working on the long-tail things, I've done plenty of it myself. It pays the bills, it can even be good engineering. But I don't think the article is right to imply that it's where most of the business value comes from.

Re: Mistakes engineers make in large established codebases

#364

Post by danjac » Fri, Jan 10, 2025, 10:34 AM UTC

bluGill wrote: post #264

danjac wrote: post #245

Earlier quoted context omitted.

Often the problem with companies running the Feature Factory production treadmill too long is you have code supporting unused features and business logic, but nobody knows any more which features can be dropped or simplified (particularly after lots of employee churn and lack of documentation). So the problem is not so much technical debt, but product debt. You can refactor, but you're also wasting time optimizing co…

I was involved with a big rewrite. Our manager had on his desk the old system with a sign "[managers name]'s product owner". Nearly every time someone wanted to know how to do something the answer was load that old thing up and figure out what it did. Eventually we did retire the old system - while the new code base is much cleaner I'm convinced it would have been cheaper to just clean that code up in place. It still…

Whether you rewrite or refactor the code is not so much the point of my comment - it's more that you should first determine what you actually need, in consultation with the project stakeholders, get rid of whatever you don't need, and then you can decide whether you need to rewrite or refactor. Cutting away the bloat will give you a better perspective on that decision.

Personally, I would lean towards refactoring - a rewrite is the "declare bankrupcy" stage of technical debt and should only be considered in extremis. For example, the original codebase was written in ColdFusion and in 2025 you can't find any ColdFusion developers (or anyone in their right mind who wants to become a ColdFusion developer). But in any case, rewriting a trimmed down codebase is easier than trying to replicate features you don't need any more.

Re: Mistakes engineers make in large established codebases

#365

Post by 59nadir » Fri, Jan 10, 2025, 1:27 PM UTC

usefulcat wrote: post #157

cratermoon wrote: post #149

Earlier quoted context omitted.

> needs to be a key leader for the part being broken out into a separate system Indeed, the developer was one of the best programmers I've known and absolutely the key person on the system. The New Guys Clique were the sort of developers, you might know some, who come in, look at the existing systems, decide it's all wrong and terrible, and set out to Do It Right.

I've seen almost this exact scenario play out, although in my case it was just one person as opposed to a clique. He had just come from a much larger company in the same business, and almost right away he proposed that we should rearchitect a significant portion of our software to match the way things were done at his previous employer. His proposed architecture wasn't without elegance, but it was also more complex a…

What was the language and proposed architecture? Nothing is quite as grating as being hired for work on an Erlang/Elixir code base and seeing basically no correct usage of the platform and it'd definitely result in an instant suggestion to start correctly leveraging Erlang, piece by piece. It's not even a question of architecture as much as it is completely ignoring what makes the platform good, IMO.

Re: Mistakes engineers make in large established codebases

#366

Post by cratermoon » Fri, Jan 10, 2025, 4:26 PM UTC

simoncion wrote: post #343

cratermoon wrote: post #307

Earlier quoted context omitted.

If the schedule is three years, and in the meantime the product being rewritten isn't getting maintenance, the company might as well go ahead and fold and save everyone pain and disappointment. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

If the product is not getting needed maintenance, then yeah, maybe. But, man, sometimes software is fit-for-purpose and can really be just be left alone for extended periods. Other times, the users of that software upgrade on a hemi-annual or annual schedule (or even LESS frequently), so they'd never notice a three month delay in new releases.

> sometimes software is fit-for-purpose and can really be just be left alone for extended periods

I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. I can think of Major Software companies that barely maintain their products yet companies stick with the garbage because what choice do they have?

Re: Mistakes engineers make in large established codebases

#367

Post by usefulcat » Fri, Jan 10, 2025, 8:06 PM UTC

59nadir wrote: post #365

usefulcat wrote: post #157

Earlier quoted context omitted.

I've seen almost this exact scenario play out, although in my case it was just one person as opposed to a clique. He had just come from a much larger company in the same business, and almost right away he proposed that we should rearchitect a significant portion of our software to match the way things were done at his previous employer. His proposed architecture wasn't without elegance, but it was also more complex a…

What was the language and proposed architecture? Nothing is quite as grating as being hired for work on an Erlang/Elixir code base and seeing basically no correct usage of the platform and it'd definitely result in an instant suggestion to start correctly leveraging Erlang, piece by piece. It's not even a question of architecture as much as it is completely ignoring what makes the platform good, IMO.

It was all c++. The existing architecture consisted of a number of different executables, which were mostly statically linked (except for stuff like the C and C++ runtime libs). His proposal was to factor out the business logic from each executable into a shared library, and then (if memory serves) we would only need a single executable that could work with any of these new shared libraries. Like a plugin architecture.

This would mean that when rolling out a new version, usually only the shared library would need to be replaced. So.. significantly more complexity, due to now having a more arms-length interface between the executable and the business logic in the shared libraries. And the payoff was.. when deploying, we would upgrade a shared library instead of an executable? Still doesn't seem worthwhile.

Re: Mistakes engineers make in large established codebases

#368

Post by simoncion » Fri, Jan 10, 2025, 9:06 PM UTC

cratermoon wrote: post #366

simoncion wrote: post #343

Earlier quoted context omitted.

If the product is not getting needed maintenance, then yeah, maybe. But, man, sometimes software is fit-for-purpose and can really be just be left alone for extended periods. Other times, the users of that software upgrade on a hemi-annual or annual schedule (or even LESS frequently), so they'd never notice a three month delay in new releases.

> sometimes software is fit-for-purpose and can really be just be left alone for extended periods I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure. I can think of Major Software companies that barely maintain their products yet companies stick with the garbage because what choice do they have?

> I suppose if the software maker is a functional monopoly in that space and the customers are cursed withe vendor lock-in, sure.

Given this statement, it might surprise you to learn that there are folks who aren't keen on software development for its own sake, and really rather dislike having to re-learn how to use their tools when those tools get significantly changed with no clear benefit to those users.

See also: the folks who are perfectly happily using "ancient" versions of -say- Photoshop, or WordPerfect, or Word or...

Re: Mistakes engineers make in large established codebases

#369

Post by _Tev » Sat, Jan 11, 2025, 12:41 AM UTC

bitcraft wrote: post #353

bricestacey wrote: post #291

Earlier quoted context omitted.

I do not believe in "boyscouting". I think if you want to leave it better, make a ticket and do it later. Tacking it on to your already planned work is outside the scope of your original intent. This will impact your team's ability to understand and review your changes. Your codebase is unlikely to be optimized for your whimsy. Worse though is when a reviewer suggests boyscouting. I've seen too many needless errors a…

Boyscouting works because you don’t need to get permission to fix tech debt when it is bundled with something else. 98% of those tickets you file to fix warts will never be addressed because the business demands that time is spent on features that make money.

Isn't the point of OP of this thread that most of those wart-fixes are pointless?

I tend to agree, if you can't sell it as a ticket you probably shouldn't work on it. And "boyscout" PRs are pain to review.

Re: Mistakes engineers make in large established codebases

#370

Post by whatevaa » Sat, Jan 11, 2025, 2:12 PM UTC

cwalv wrote: post #287

zwnow wrote: post #180

Earlier quoted context omitted.

Thats not how software engineering works in a business setting though? Not a single company I have been in has the time to first fix the existing codebase before adding a new feature. The new feature is verbally guaranteed to the customers by project managers and then its on the dev to deliver within the deadline or you'll have much greater issues than a inconsistent codebase. I'd love to work in a fantasy company th…

> I'd love to work in a fantasy company that allows for fixing legacy code You're not supposed to ask. It's like a structural engineer asking if it's okay to spend time doing a geological survey; it's not optional. Or a CFO asking if it's okay to pay down high interest debt. If you're the 'engineer', you decide the extent it's necessary

Totally no. Structural engineers also have to consider real life constraints, including cost. We are talking about working with existing structures, it's too late for geological surveys.