Mistakes engineers make in large established codebases • Hacker News Board

Re: Mistakes engineers make in large established codebases

#291

Post by bricestacey » Wed, Jan 08, 2025, 4:45 PM UTC

Kinrany wrote: post #212

pablobaz wrote: post #62

In my experience with very large codebases, a common problem is devs trying to improve random things. This is well intentioned. But in a large old codebase finding things to improve is trivial - there are thousands of them. Finding and judging which things to improve that will actually have a real positive impact is the real skill. The terminal case of this is developers who in the midst of another task try improve o…

Do you think boyscouting, "leave it better than you found it" is misguided as well?

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 after someone happened to "fix a tiny little thing" and then fail to deliver their original task and further distract others trying to resolve the mistake. I believe clear intention and communication are paramount. If I want to make something better, I prefer to file a ticket and do it with intention.

Re: Mistakes engineers make in large established codebases

#292

Post by hinkley » Wed, Jan 08, 2025, 4:46 PM UTC

huijzer wrote: post #181

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…

And then at some point the codebase becomes so unusable that new features take too long and out of frustration management decides to hire 500 extra programmers to fix the situation, which makes the situation even more slow. As I understand, there is a balance between refactoring and adding new features. It’s up to the engineers to find a way to do both. Isn’t it also fair if engineers push sometimes back on managemen…

Or it becomes so unusable that the customers become disenchanted and flee to competitors.

If management keeps making up deadlines without engineering input, then they get to apologize to the customer for being wrong. Being an adult means taking responsibility for your own actions. I can’t make a liar look good in perpetuity and it’s better to be a little wrong now than to hit the cliff and go from being on time to six months late practically overnight.

Re: Mistakes engineers make in large established codebases

#293

Post by hinkley » Wed, Jan 08, 2025, 4:49 PM UTC

danjac wrote: post #245

huijzer wrote: post #181

Earlier quoted context omitted.

And then at some point the codebase becomes so unusable that new features take too long and out of frustration management decides to hire 500 extra programmers to fix the situation, which makes the situation even more slow. As I understand, there is a balance between refactoring and adding new features. It’s up to the engineers to find a way to do both. Isn’t it also fair if engineers push sometimes back on managemen…

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…

In the same way people go to their doctor or dentist or mechanic too late and prevention and sometimes even the best treatments are off the table, software developers (particularly in groups vs individually) love to let a problem fester until it’s nearly impossible to fix. I’m constantly working on problems that would have been much easier to address 2 years ago.

Re: Mistakes engineers make in large established codebases

#294

Post by dktoao » Wed, Jan 08, 2025, 4:59 PM UTC

This is good advice but only it has been followed from the beginning and consistently throughout the development of the original code. It is applicable to large organizations with lots of resources who hire professional developers and have a lot of people who are familiar with the code that are active in code reviews and have some minimum form of documentation / agreement on what the logic flow in the code should look like (the article does not claim otherwise). But I would implore those who work at the 80% of other companies that this advice is nearly useless and YMMV trying to follow it. The one thing that I think is universally good advice is to try and aggressively remove code whenever possible.

Re: Mistakes engineers make in large established codebases

#295

Post by hinkley » Wed, Jan 08, 2025, 5:00 PM 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…

Rewrites are much like any act of self improvement. People think grand gestures and magical dates (like January 1 or hitting rock bottom) are the solution to turn your life around. But it’s little habits compounding that make or break you. And it’s new habits that kill old ones, not abstinence.

I worked with another contractor for a batshit team that was waiting for a rewrite. We bonded over how silly they were being. Yeah that’s great that you have a plan but we have to put up with your bullshit now. The one eyed man who was leading them kept pushing back on any attempts to improve the existing code, even widely accepted idioms to replace their jank. At some point I just had to ask him how he expected all of his coworkers to show up one day and start writing good code if he won’t let them do it now? He didn’t have an answer to that, and I’m not even sure the question landed. Pity.

The person who promised him the rewrite got promoted shortly before my contract was up. This promotion involved moving to a different office. I would bet good money that his replacement did not give that team their rewrite. They’re probably either still supporting that garbage or the team disappeared and someone else wrote a replacement.

That whole experience just reinforced my belief that the Ship of Theseus scenario is the only solution you can count on working. Good code takes discipline, and discipline means cleaning up after yourself. If you won’t do that, then the rewrite will fall apart too. Or flame out.

Re: Mistakes engineers make in large established codebases

#296

Post by tomohawk » Wed, Jan 08, 2025, 5:03 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

It's why Scotty was always giving longer estimates that Kirk wanted, but Kirk was also able to require an emergency fix to save the ship.

The estimate was building in the time to get it done without breaking too much other stuff. For emergency things, Scotty would be dealing with that after the emergency.

If your captain is always requiring everything be done as an emergency with no recovery time, you've got bigger problems.

Re: Mistakes engineers make in large established codebases

#297

Post by jowdones » Wed, Jan 08, 2025, 5:05 PM UTC

dktoao wrote: post #294

This is good advice but only it has been followed from the beginning and consistently throughout the development of the original code. It is applicable to large organizations with lots of resources who hire professional developers and have a lot of people who are familiar with the code that are active in code reviews and have some minimum form of documentation / agreement on what the logic flow in the code should loo…

[dead]

Re: Mistakes engineers make in large established codebases

#298

Post by hinkley » Wed, Jan 08, 2025, 5:07 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 stayed at a place that was decades old, in part to decipher how they’d managed to get away with not only terrible engineering discipline but two rewrites without going out of business. I figured it would be good for me to stick around at a place that was defying my predictions for once instead of fleeing at the first signs of smoke. I’ve hired onto places that failed before my old employer did at least twice and I feel a bit silly about that.

I wasted a lot of my time and came away barely the wiser, because the company is spiraling and has been for a while. Near as I can figure, the secret sauce was entirely outside of engineering. If I had to guess, they used to have amazing salespeople and whoever was responsible for that fact eventually left, and their replacement’s replacement couldn’t deliver. Last I heard they got bought by a competitor, and I wonder how much of my code is still serving customers.

Re: Mistakes engineers make in large established codebases

#299

Post by hinkley » Wed, Jan 08, 2025, 5:11 PM UTC

zwnow wrote: post #183

huijzer wrote: post #181

Earlier quoted context omitted.

And then at some point the codebase becomes so unusable that new features take too long and out of frustration management decides to hire 500 extra programmers to fix the situation, which makes the situation even more slow. As I understand, there is a balance between refactoring and adding new features. It’s up to the engineers to find a way to do both. Isn’t it also fair if engineers push sometimes back on managemen…

The issue is that management usually doesn't care. Personally I usually have about 3-4 days to implement something. If I can't deliver they will just look for more devs, yes. Quantity is what matters for management. New New New is what they want, who cares about the codebase (sarcasm). Management doesn't even know how a good codebase looks. A bridge that is missing support probably wouldn't have been opened to the pu…

That’s why consistent messaging matters. If everyone agrees to make features take as long as they take, then management can’t shop things around. Which they shouldn’t be doing but we all know That Guy.

When children do this it’s called Bidding. It’s supposed to be a developmental phase you train them out of. If Mom says no the answer is no. Asking Dad after Mom said no is a good way to get grounded.

Re: Mistakes engineers make in large established codebases

#300

Post by hinkley » Wed, Jan 08, 2025, 5:11 PM UTC

staunton wrote: post #200

zwnow wrote: post #183

Earlier quoted context omitted.

The issue is that management usually doesn't care. Personally I usually have about 3-4 days to implement something. If I can't deliver they will just look for more devs, yes. Quantity is what matters for management. New New New is what they want, who cares about the codebase (sarcasm). Management doesn't even know how a good codebase looks. A bridge that is missing support probably wouldn't have been opened to the pu…

> A bridge that is missing support probably wouldn't have been opened to the public in the first place. That's not always been the case and came to be because people have died... Is anyone going to die if your codebase is an unmaintainable mess?

Companies die because nobody is willing to work on the code anymore.

If VCs ever came to expect less than 90% of their investments to essentially go to zero, maybe that would change. But they make enough money off of dumb luck not leading to fatal irreversible decisions often enough to keep them fat and happy.