[JackMorgan]

It's called survivorship bias (1).

The only people pointing to PHP as the right choice that kept them from ruin are those that used it successfully. Therefore, they were building something that fit well with PHP's benefits and didn't expose too many of it's weaknesses. But no one knows for sure exactly what about that project made it a good candidate for a PHP monolith, because we don't really have any science around software engineering, just hearsay and fashion.

Having rescued several 10+ person year PHP projects from ruin, none of them were on the edge because of the language itself. However, the people building those systems made an incredible mess in a short time. I think each language attracts a certain type of developer and comes with it's own community baggage. The PHP community has some highly questionable best practices. But this is true of all programming language specific communities. They tend to be insular and have a lot of "winning the last war" advice for working around the shortcomings of the language's previous major version that have been fixed in the current major version.

(1) https://en.wikipedia.org/wiki/Survivorship_bias

[ThalesX]

> Having rescued several 10+ person year PHP projects from ruin

How did you rescue them? What are your views on Laravel?

[JackMorgan]

The teams were generally adding more bugs per release then they were fixing. Many bugs were caused by duplicated code: "I fixed the bug, but only in 1/18th of the places it manifests."

The projects were using Zend framework 2. We didn't change really anything about the text stack at all.

The solutions were generally three pronged. This isn't to bash anyone, but every failing project I've seen is a skill, talent, or discipline issue, not a technical one. So recusing projects tends to be about training, mentorship, and guidance. Sure, you fix things along the way, but that's more to prove to the devs that you know what you're talking about, so they start to fix things themselves.

First, start a root cause analysis on bugs before fixing them. This often meant that instead of another if statement in the UI because of bad state, there was a larger fix needed to prevent the bad state entirely. These bigger changes were scary, but they quickly turned these projects from spending all their time in emergencies into only a few hours a week.

Second tool was to deduplicate and unit test code as much as possible. No more copy-pasting whole files every time there was a slightly different use-case required.

Third, to stop treating the database like a PHP ORM connection and start treating it like a distinct tool. Things like turning serialized PHP arrays from a single column into separate tables allowed us to start using SQL to query data instead of pulling all records into memory to filter and sort. This rapidly improved performance, which meant fewer support issues.

All boring, bog standard stuff. One project we started a second service in .NET to be the location of new features because half the team didn't want to use PHP anymore. The idea was they could slowly migrate endpoints to the .NET project. But that didn't survive. They got bored with a slow and safe conversion and convinced upper management to approve a total rewrite in .NET with a whole different team building out a microservice mess. The rewrite has been ongoing for 18 months now without a release. I heard they finished their first feature a few months ago, but still aren't live. Meanwhile the PHP project just keeps chugging along. Just goes to show, it's rarely the technology that causes issues, it's the team.

I don't really know anything about Laravel. I'm not really a PHP guy, I'm a project rescuer. Just happens to be most projects I get called into are PHP, C#, and Visual Basic. I've heard really good things about Laravel, but even ZF2 can be made safe, secure, performant, and reliable. It just takes discipline and the right team. That being said, I would consider PHP to be a language that is hard to hire for. There's just so many developers that flood the inbox who don't even know what a function is.

I will say, when I took a contract to build a greenfield web dashboard at the start of the year, I chose .NET 6 and C#. The platform and ecosystem is fine. I've shipped Java, Python, JavaScript, Ruby, Perl, OCaml, Haskell, Clojure, F#, and VB.NET. I picked C# for this project because the company already has a couple dozen C# developers who are pretty talented. I figured if I shipped them something they were comfortable with maybe they'd hire me again down the road.

[tored]

Very common for older PHP projects to store PHP serialized strings in the database. Horrible performance and of course gets easily corrupted of not handling concurrent updates properly.

Rewrites rarely succeeds, it is a typical fallacy for a team to believe that their problems lie in the language they are using and not in themselves. Seen it too many times.