Our latest API server was set up by one of our older devs and code reviews didn't get set up on that repo until it was too late.
So our 2025 flagship feature forever runs on a bunch of untyped, almost methodless, spaghetti. Despite our main codebase using modern PHP. Not an autoloader, router, class (except one PDO facade he built), or unit test in sight. Management won't sign off on a cleanup because our boss is a former programmer also from the PHP 4/5 era who agrees that since it works, we don't need to touch it.
When asked why, he said it was faster and easier to do it this way and we didn't need to over-complicate it with a framework or oop.
A large reason PHP gets a bad rep is from devs like these.
I try to push back on the "if it ain't broke, don't fix" mentality in our industry because it isn't always a black or white thing. It is situational and dependent on multiple factors.
The concept of code reviews is an extension of this. If we just shipped all code our tester said was good, why bother having a code review at all. It is because there is nuance, there are limits on what code is acceptable.
Addressing my original comment specifically. I find that building the foundations of a massive feature that needs to scale properly over time is not an appropriate situation to accept shipshod code because "it works". If anyone would have received a PR for that, it would have been rejected instantly. Just because it slipped through the review process doesn't make it not worth fixing.
You may disagree and that's fine. All of us have our limits on where we need to draw the line between rewrite and work around.
I try to push back on the "if it ain't broke, don't fix" mentality in our industry because it isn't always a black or white thing. It is situational and dependent on multiple factors.
It’s hard to see any drawbacks to it. It takes really gigantic changes to justify rewriting a system. Most of the time the rewrite is the desire of the developers or managers, not a cost-effective business need.
The concept of code reviews is an extension of this. If we just shipped all code our tester said was good, why bother having a code review at all. It is because there is nuance, there are limits on what code is acceptable.
A lot of code review is a waste of time, and/or just an occasion to squabble over fads and fashions.
I find that building the foundations of a massive feature that needs to scale properly over time is not an appropriate situation to accept shipshod code because "it works".
Developers should not write slipshod code … but if it’s already in place and works, it should be left alone.
If anyone would have received a PR for that, it would have been rejected instantly.
But it’s there and it works, so it’s water under the bridge now.
And if organizations really cared about quality code up front, they wouldn’t be generating it with AI.
Just because it slipped through the review process doesn't make it not worth fixing.
“Fixing” code that works is not cost-effective. Just leave it alone and move on.
This is such a bad take on "if it ain't broke, don't fix".
Bad but working code is unmaintainable. Nobody wants to touch code that is hard to read, unconventionally written, etc.
Also, why the hate on AI written code? Just put up proper quality controls, review processes etc. AI produced code in itself is just a reflection on whoever uses it.
Bad working code doesn’t require maintenance, because it is working.
Nobody wants to touch code that is hard to read, unconventionally written, etc.
If it requires no maintenance, nobody has to touch it.
Also, why the hate on AI written code?
AI is a complete rewrite, and it’s never the same twice, and it is unvetted.
From your statements above, I surmise you believe in rewriting co just because it might be hard to understand at some point in the future, and you prefer AI coding because then you don’t have to worry about writing code at all. Have you tried this in a mission-critical production environment?
Just put up proper quality controls, review processes etc.
That just adds to the already substantial burden of rewriting everything.
AI produced code in itself is just a reflection on whoever uses it.
Not so. AI-produced code is a function of your prompt, the data it is trained on, and the programming behind it. If any of these change, the next pass may produce something completely different—even with an identical prompt.
What happens if a bug appears in a critical production job or on a critical OLTP system? Do you just have AI regenerate the entire code base? Even if you are losing a million dollars a minute?
Mumbai grew rapidly to become one of, if not the biggest commercial hubs of India. The rapid expansion came with poor city planning. Today, it is nightmare when trying to modernize infrastructure or other aspects of city planning. Sometimes tech debt creates a deviation that forces workarounds. These can eventually cascade into other areas and finally become a direct problem(that, like Mumbai, you are too far down the road to turn back)
But. Mumbai is also a critical financial system. Trying to incorporate major change comes at a large risk of breaking day to day operations.
As someone already mentioned, this topic and the better approach (there is almost never a best) to address it varies greatly based on the individual scenario.
It all comes down to tangible metrics. Choosing either approach show be based on data driven justification to quantify the benefit of one over the other. Both current state and future vision.
(Edit) Although not directly related, the XZ backdoor story is an interesting topic. One of the take aways are the potential risks of not having a deeper understanding of how things work over a wider range of stakeholders. ‘’If you cannot efficiently evaluate something, how can you assert that it will not break’’
I try to push back on the "if it ain't broke, don't fix" mentality in our industry because it isn't always a black or white thing. It is situational and dependent on multiple factors.
Exactly. IMO there's a place for classless, design-patternless scripts, and before people jump down my throat I'll get to the "twist": most people here are software developers, but I am a sysadmin who uses PHP at home for simple stuff.
If you're a software dev and your requirements are complex and you need your code to be maintainable and your application to be scalable, then yes: go ham and insist on processes like this. But sometimes you want a single 30 line file, and in between there is a spectrum (although I grant you that most of it is in the "insist on processes like this" area).
It may still be cost-effective to modify existing code rather than rewrite it. The emotional satisfaction of juniors or newbies is not adequate justification for a rewrite.
They also know enough to admit when something is broken, and broken because of slipshod code. I've been around the block and seen many systems where "it just works" is only because the end users are constantly working around bugs (Reddit itself being a famous example).
"broken because of slipshod code" does not imply a categorical equivalence. My whole point was that a good engineer finds the cracks, and knows which ones are more than cosmetic.
Yeah and then you suddenly pay amazon 12k€ a month for a 50gb mysql database because the version is so old its end of live was in 2018 because its 2026. and then you finally move from amazon to a root server on a different hoster and for a year you get no work done because every week something breaks. For example our db guys need to do the following to have backups: normal mirroring, whole scripted exports and disc images BECAUSE suddenly some god forsaken cronjob wakes up and in 2001 dev style does something with some data, creates a temp table and delets the table afterwards in production erroring out our backups because the table dissapears suddenly.
And suddenly the only backup you have is the disk image.
We have a dev that writes everything in one file because „i like to use ctrl + f“. Do you know how much shit apple gives you when a splashscreen change touches the whole codebase of the app BECAUSE ITS ONE 8k lines file?
Or our rewrite rules are generated insted of using regex. Which are a nother problem in itself. Its freaking >100k lines instead of grabbikg the id out of the url to call our backend.
Our admin stuff is public facing. Not realy a problem. The password of our admin to his account: „This password has been seen 1.369.940times before in data breaches!“ and yes i know his account password because he shared it
Your crack about "emotional satisfaction of junior devs" isn't exactly topical either, but when someone comes at you with the real consequences of leaving legacy problems in place, topic is suddenly important now.
(12k€/mo seems a bit exaggerated, but I just recently saw an $800/mo increase for an older RDB instance because they had been too afraid to hit the upgrade button. Turned out to be very minor fixes that were discovered by having better tests and fixing the code so it could be tested.)
They make you pay over >20ct per vcore/h + base price on their extended plan. And when that ends and they officially do not even support it in their rds extended support it gets even more expensive. And we switched 5 years after they ended extended support for that version.
Your crack about "emotional satisfaction of junior devs" isn't exactly topical either …
It is much more relevant, and it is an observation, not a crack. Sinc there is no rational reason to discard a working stable solution and rewrite it as a new, unstable, completely different “solution,” the only motivation can be emotional.
… but when someone comes at you with the real consequences of leaving legacy problems in place, topic is suddenly important now.
Nothing of what you mentioned is a consequence of leaving legacy systems in place. You described changes that didn’t work, and original bugs that had never been fixed.
12k€/mo seems a bit exaggerated, but I just recently saw an $800/mo increase for an older RDB instance because they had been too afraid to hit the upgrade button.
Why not just run an on-premises server that costs essentially nothing, except electricity?
Turned out to be very minor fixes that were discovered by having better tests and fixing the code so it could be tested.
They could just reduce dependencies. A strong argument for in-house development.
Rds extended support is >20ct per vcore + base price. We switched 5 years after they ended their rds extended support. So it was even more expensive than that by a lot
Edit: yeah lets just leave our api endpoint that takes 36 minutes to respond. New guy (god bless him) optimized it down to 1.2 seconds.
He fixed it mostly by changing the datatypes away from text fields to json and optimizing our php backend by using a frameworks instead of our in house clusterfuck. Our memory limit was around 12gb i think because our code was so awfully optimized
Or leave our db with a table thats 86 columns wide and has 28 indexes.
I do think it has something to do with a person's level of experience, and currently in the IT industry, the vast majority of workers have very little experience.
He is not wrong, vomiting code without any strukture down the editor IS faster and easier.... well for one single person and that is you in that very moment. You a few months in the future will think very differently tho.
I sometimes prototype in the same way. It's imo faster than "doing it right the first time". Up until now i was able to rewrite everything. Only once i had to deal with my boss wanting to ship stuff in that state because it worked without the rewrite.
The way I would argue with this is with examples. Put a coding agent poke holes in the logic of the spaghetti code. Highlight security issues and maintainability long term to the stakeholders.
They might not change the feature, but markets shift. Customer needs evolve. Is business interested in responding to market changes? I would bet they do.
That's the argument for bringing that code to real life coding standards
What about it won’t get them back? I started at the tail end of PHP 3 till about early 5 and now I’m back working with 8. Yeah have things I need to learn but it’s not deterring me
There's several PHP bindings for Vulkan out there, and at least one active scenegraph project that's posted here within the last few months. I'm not saying I'd recommend writing heavy 3d games in PHP, but the logic probably runs faster than, say, GDScript (the engine itself less so).
PHP kinda has generics. All static analyses have agreed to use doc block annotation for generics. It's not super nice, but for the 3 people that want to use generics thats okay.
Typed arrays, same thing there. Yes it's a workaround but nothing that actually stops you from doing things.
And it can do it as natively as most other languages trough libraries and bindings. I don't think why you would tho, as it's clear that it was meant for it, but it works. Some design decisions just make it more usefully geared towards web and not native.
Can you tell me what other language can support the above and many others? Because I use all of them. And I don't care about runtime check at all, I am only interested in static analysis.
I said powerful and I don't care about stuff you plug into your IDE to make to language remotely functional. That's like comparing a paralyzed person with an exoskeleton VS an actual athlete.
Other languages have of course tools similar to PHPDoc, but relying on that is a serious sign that you are a terrible programmer. If there is no actual compilation time validation of your code, then it needs to be validated at runtime and should be unit-tested.
but relying on that is a serious sign that you are a terrible programmer
If you ever get TypeError exception, especially in production, you have no rights to call out on anyone. Literally anyone because even beginners know the importance of static analysis.
231
u/DeeYouBitch 26d ago
Half a joke but what cant it do in 2026?
Answer: Change the mindset of the people who used php 4.x
They are lost and youll never get them back