This is how you grow your web app indefinitely:
1. Strip the codebase of all frameworks
2. Ban DRY principle. Don't reuse the code, period.
3. When feeling the urge to write a unit test, refactor the code instead.
4. When seniors “discover” a new “paradigm” that applies to the codebase and want to make a framework, rotate them.
5. Profit!

Nah, the opposite of dry is making stuff generic. And if you have everything generic and your product becomes bigger, you have to implement exceptions and stuff and make the generic system support everything in the end. Making those exceptions becomes harder and harder to make it all work together. If you actually did duplicate code, for example html pages, in both pages you can implement easy an exception without breaking something else. If you want to display something on both pages, yes, ofc, you have to do that two times. But often it's better to do that. I worked at a company that did repeat itself full time regarding html templating and it was the right choice. It was for a hosting management platform. It really paid of those have a specific template for every page instead of making stuff too generic.

It's more a discussion of doing initially work 'smart' or initially work 'hard'. Also, repeated code doesn't have to be changed by hand. You can make tools to do batching.

Stripping of all frameworks, heavy agree for things that you do well understand yourself. If you understand the subject very well yourself - a framework is full of choices you wouldn't take. I'm writing my own form library now that executes server side validation and shows it life client side so it feels like client side validation. Benefit is, that I only have one layer of validation. Also this validation is applied on model level. So the database will never have wrong data, it's just not possible by design. Every field has support for regex and you can override the the validate method completely to do "check if user already exists" for username field for example.

Why write this myself? There are a lot of forms libraries. Well, in my opinion they're not good. They're general purpose and do only the minimum and if they do more, it's even worse.

Will it pay off in time spent? Not sure, but i'm 100% happy about my implementation now. That's not the case when using framework.

Not only do you have to find all occurrences of something to change it, but you're strictly forbidden from automatically checking that they're the same for future reference, and you've fired everyone who knew the complete list because they invariably attempted to formalize the dispatch in code to mitigate the chaos.

Instant legacy project powder, stir in a glass of cold cash for 2 years for an accurate imitation of a 20 year old codebase.

Nah, just hire manager, or better two and your codebase will become infinite!

Pile

Of

Crap

@lorentz have you tried my strategy? Because I tried both mine way and the industry standard way, and mine worked better. Less team burnout, quicker delivery times, fewer bugs, higher morale.

Also, “rotate” here doesn't mean “fire”, it means moving them to another project/area of the codebase.

@kiki You evidently have more data than me, but the project I'm currently on is suffering from those exact issues. Duplicate logic in innumerable places that has to be kept in sync manually, domain knowledge gone with the original authors, no unit tests meaning constant hidden breakage, and lucky initialization due to a shitty bespoke DI scheme that didn't work everywhere and so later work didn't even use it. Anyone with even close to a sweeping knowledge of the codebase is assigned to fix the constant stream of stupid bugs that could be caught easily if we had multiple layers of automated tests rather than one or two e2e UI tests per feature.

I'll readily believe that you did these things and your teams were happy and productive, but it wasn't just because of this, you did something else really well that isn't trivial, because I cannot pinpoint why this project is in such a shit state.

@lorentz one year ago, if you asked me to name one thing that made all the difference, I would've named sinking hours upon hours into designing the DB schema. As some smart programmer said, if you get your data structure right, the rest of the code just writes itself.

But if you ask me now, I'll say it was the principle of one file per route, no matter the LOC length. Code is copied and pasted, never reused. Even if the file is 5000 lines long (never happened, may happen in the future), you KNOW that if a route breaks, the bug IS within this file. And you know that if you change anything — anything at all — within the logic of one route, the remaining routes won't change at all.

During my 10 years of experience, I only had like 3 cases when I had to change every route. Yet I had a LOT of cases when had to change just one route's logic without touching anything else, but it was hard because of the cult of DRY. Everything is an import, everything is a shared trait. Bwaagh.

@lorentz I'll admit that in this knucklehead hardcore DRY environment, unit tests are islands of sanity in this stormy ocean of shit. But if it's just one file, and there are no GOTO statements because it's JS, then… yeah, you already know that I didn't need unit tests.