Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes engineers make in large established codebases

seangoedecke.com

Post reply on HN
Print view View original

341–350 of 384 posts

Re: Mistakes engineers make in large established codebases

#341

Post by jongjong »

tmnvdb wrote: post #236
jongjong wrote: post #144

Earlier quoted context omitted.

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…

In my current job I did a PR in the first week of joining. It was reviewed after exactly 2 years. I had to rewrite the whole PR because of the affected lines had changed. Of course I did not remember at all what is was about. Some PRs are faster but some are slower as well.

Maybe you meant getting a PR merged. Then 3 days seems possible depending on the approach. At my current company, the team is small so approval process is quite fast and not too fussy.

Re: Mistakes engineers make in large established codebases

#342

Post by simoncion »

harrall wrote: post #289
simoncion wrote: post #261

Earlier quoted context omitted.

> You can do successful rewrites but your rewrite has to be usable in production within like a month. I strongly disagree with this, and it reminds me of one of the worse Agile memes: "With every commit, the product must be production-ready.". [0] The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work. [0] I've worke…

OK so you're actually right, but the actual criteria of "whether you can do this" depends on a lot of factors from the project to the people. But there's no way to really describe it. It's like explaining to somehow how to parallel park or do a kickflip... you can only explain it so much. I like to say "it should be usable in production soon" because it's generally a good approximation that takes into account what yo…

> It's an upgrade from advice like Joel's who just say "IT NEVER WORKS"

What you originally said ("It must be usable in production within a month") is equivalent to "Just don't do it, because IT NEVER WORKS" for all but the smallest, simplest projects out there in Professional Programmer land. [0]

> But there's no way to really describe it.

There really is a way to describe it:

"The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work."

Establishing that schedule is the same sort of cost/benefit and expected-level-of-difficulty analysis that should be done before planning any nontrivial work in Professional Programmer land. All but the most green or most sheltered-from-Process programmers are at least aware of this analysis. Many of those who are aware of it have participated in it.

[0] Or the most well-designed projects, which have small, easily understood pieces with easily-comprehensible interactions with the rest of the system, that can be quickly and easily replaced with new pieces. There's not much out there like that... and I'd imagine the task of "making major changes to how many of those pieces interact with each other" wouldn't be usable in production in a month for most of those systems.

Re: Mistakes engineers make in large established codebases

#343

Post by simoncion »

cratermoon wrote: post #307
simoncion wrote: post #261

Earlier quoted context omitted.

> You can do successful rewrites but your rewrite has to be usable in production within like a month. I strongly disagree with this, and it reminds me of one of the worse Agile memes: "With every commit, the product must be production-ready.". [0] The rewrite has to be generally not behind schedule. Whatever that schedule is is up to the folks doing the work and the managers who approve doing the work. [0] I've worke…

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.

Re: Mistakes engineers make in large established codebases

#344

Post by lmm »

edanm wrote: post #274
lmm wrote: post #266

Earlier quoted context omitted.

> Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Linux is notoriously fragmented/duplicative, and an OS isn't the solution to anyone's actual business problem. A well-factored solution to a specific problem would be much smaller, compare e.g. QNX. > Facebook is probably more lines of code. IIRC Facebook is the last non-monorepo holdout among the giants, they genuinely…

I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts. As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc. Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like…

> 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, so it's what devs get rewarded for, so it keeps happening even as the RoI drops lower and lower (and in many cases eventually goes negative - but this is masked because the core idea was good enough then the product as a whole is still profitable). At "best" a bunch of esoteric features act as a de facto moat that can shut out the competition in a tickbox-feature-comparison, rather than being something that's actually adding value in day-to-day use.

Re: Mistakes engineers make in large established codebases

#345

Post by liontwist »

Supermancho wrote: post #276
liontwist wrote: post #127

Earlier quoted context omitted.

This sounds like you are missing important context. Here is a similar conversation: "Why do I have to use the system button class. I implemented my own and it works." "Because when the OS updates with new behavior your button may break or not get new styling and functionality" "But this works and meets the spec, that's 10x harder"

More like we have to use the god object to make all http calls for consistency in logging, despite this being a gcp pubsub.

Find the context you are missing and if it’s bad reason you will understand their perspective more and be able to persuade them.

Re: Mistakes engineers make in large established codebases

#346

Post by edanm »

lmm wrote: post #344
edanm wrote: post #274

Earlier quoted context omitted.

I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts. As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc. Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like…

> 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, allowing scripting, wasn't released until 1993. Do you think think Excel circa 2000 is as good as Excel today is? I'm sure it's roughly similar, but I'm just as sure there are many features that I would miss.

And that's not even getting to the fact that Excel lost a ton of marketshare to Google Sheets, because it was too late to adopt what is Sheet's biggest feature - collaborative editing. I'm sure in 2005 you could've made the case that Excel already has all the business value it needs, and trying to add something like collaborative editing is just a corporate waste of time, a totally "esoteric" feature that no one really needs and doesn't provide value, and is only there to get managers promoted or to get devs working on something "cool". Yet arguably it was a critical thing they needed to get done and didn't.

Anyway, I'm sure you're right a lot of the time. I just think blankly applying this statement is very wrong, when real people in the real world are sometimes working on systems, 10, 20 or sometimes even 50 years old.

Re: Mistakes engineers make in large established codebases

#347

Post by cess11 »

zwnow wrote: post #317
cess11 wrote: post #305

Earlier quoted context omitted.

I was in an organisation that made decent money on a system built on Laravel 3, I think. The framework was written in an only static classes style, which they over ten years had run with while building the business so everything was static classes. Once you have a couple of million lines of that, rewrite is practically impossible because you need to take the team of two OK devs and a junior off firefighting and featu…

I usually am in favor of a complete rewrite. I'd also prefer to not grow projects into multi million line monoliths. Just make multiple smaller ones that can interact independently with each other. Much simpler structure. Also safer in the long run.

You actually believe that? Distributed systems are simpler than monolithic? In PHP?

This business wouldn't exist if they attempted to follow your advice, because they weren't able and anyway didn't have the money to hire that many developers. There were a couple of subsystems they tried to implement the way you suggest, e.g. one for running certain background jobs.

It was a database table with one row per type of job and a little metadata like job status and a copy of the input. They started jobs by sending a HTTP request. This was a constant source of manual handling, because things started jobs and then crashed and never reset the status and things like that. You could respond that they should have used a message queue instead and so on, but the thing is, they didn't know how to build reliable distributed systems. Few developers do.

Re: Mistakes engineers make in large established codebases

#348

Post by forty »

galimaufry wrote: post #104
bdangubic wrote: post #75

Earlier quoted context omitted.

100% but mess or not - it works - otherwise you’d have no option but to touch it

Sometimes it doesn't work and no one can tell.

Sometimes it doesn't work, but fixing the mess is too expensive and we don't have time

Re: Mistakes engineers make in large established codebases

#349

Post by StellarScience »

sfink wrote: post #310
StellarScience wrote: post #168

Earlier quoted context omitted.

Great points, I'd just add: > A lot of inconsistency is the result of unwillingness to fix other people's stuff Agree, so we find it best to practice "no code ownership" or better yet "shared code ownership." So we try to think of it all as "our stuff" rather than "other people's stuff." Maybe you just joined the project, and are working around code that hasn't been touched in 5 years, but we're all responsible for i…

> That requires a high trust environment; I don't know if it could work for Firefox where you may have some very part-time contributors. Ironically, that's why it works for Firefox. Contributors follow a power law. There are a lot of one-shot contributors. They'll be doing mostly spot fixes or improvements, and their code speaks for itself. Very little trust is needed. We aren't going to be accepting binary test blob…

> All in all, the open nature of Firefox causes it to be fundamentally built on trust, to a larger extent than seems possible in most proprietary software companies.

Nice! We're still small so we somehow can keep that level of trust, but I always worry about how things may change for the worse as we grow. Mimicking the open source model as much as we can, even within a small private company, has worked well for us so far.

> > ... clang-format and clang-tidy to automate some of the simpler things, also goes a long way.

> 100% agree. It's totally worth it even if you disagree with the specific formatting decisions made.

So true! 5-6 years ago we had to make open source contributions to both clang-format and clang-tidy for several months to get them to support closer to our preferred style before we could get the "ok, close enough" buy-in across the company to implement automated formatting. (Mostly bug fixes for evidently rare flag combinations, but also a few small new features.)

In retrospect it was completely unnecessary - simply relying on automated formatting is sooo much better than any specifics of the formatting. I'm still glad we did though, as it made both tools better. We earned the maintainers' trust with a few early PRs, and remained active contributors for a while, but haven't contributed much lately.

(Posted on Firefox mobile... Thanks!)

Post reply on HN