Laravel Inventor Tells Devs To Quit Writing 'Cathedrals of Complexity' (theregister.com)
- Reference: 0178979470
- News link: https://developers.slashdot.org/story/25/09/02/1829251/laravel-inventor-tells-devs-to-quit-writing-cathedrals-of-complexity
- Source link: https://www.theregister.com/2025/09/01/laravel_inventor_clever_devs/
> Developers are sometimes drawn to building "cathedrals of complexity that aren't so easy to change," he said, speaking in a podcast for maintainable.fm, a series produced by Ruby on Rails consultancy Planet Argon.
>
> Software, he said, should be "simple and disposable and easy to change." Some problems are genuinely complex, but in general, if a developer finds a "clever solution" which goes beyond the standard documented way in a framework such as Laravel or Ruby on Rails, "that would be like a smell."
>
> A code smell -- for the uninitiated in the The Reg readership -- is a term developers use for code that works but may cause problems at a later date. Otwell described himself as a "pretty average programmer" but reckons many others are the same, solving basic problems as quickly and efficiently as they can.
[1] https://www.theregister.com/2025/09/01/laravel_inventor_clever_devs/
Unfortunately... (Score:2, Flamebait)
...theres a breed of programmer who uses writing complex code as silent bragging rights and boasting "look at me" it says, "bet you cant understand this easily because I'm l33t and you're a grunt". Theres also another breed who simply cant think in a logical fashion and their code is an unintentional rats nest that probably doesnt work anyway but they're less common as they usually get the boot from companies during their probationary period.
Easy fix (Score:2)
Use Symfony. Laravel is like a poorly thought out, feature deficient, grab bag of libraries based on the great work done for Symfony.
Just use Symfony.
Re:Easy fix (simple and disposable and easy) (Score:4, Insightful)
I just stick with what I can write in vanilla PHP that is "simple and disposable and easy to change" to use his phrase. I've tonnes of little things on my LAN, dozens of lines, hundreds at most, to do simple tasks. You can read the entire thing in a few minutes, if necessary just rewrite the whole thing in a few minutes. As soon as you have 10k's or more of lines, you need to do organisational gymnastics. If you want to use a large framework, that starts constraining how you deploy: vs just stick 5 .php files in a folder under htdocs somewhere and done.
You can do a lot with PHP and no framework, and I prefer to stick to that. My solution to the problems of code complexity is simply not to have the complexity if it can be avoided.
Re: (Score:3)
That's fine for hobby programming, but sadly companies now do all their PHP coding with frameworks, either Symfony or, more commonly, Laravel. I'm guessing because they think it makes their developers more like replaceable cogs. No need to demonstrate real coding proficiency, just experience with the chosen framework.
Typical (Score:2)
A guy who maintains a PHP framework is telling coders "just stick to the framework bro". Surprise surprise.
Genius admires simplicity... (Score:3)
...mediocrity admires complexity.
Joel on Software explained it in 2000 (Score:3)
[1]Joel on Software [joelonsoftware.com] said this about complex code back in 2000:
> Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. ...
> Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
> When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
> You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
It is true today. All that complex code is money: it is functionality the user (or the marketing folks) want to sell more, to provide better service, or to differentiate. Simple code is for textbooks. Complex, crufty, miserable code reflects the complexity of a successful business or a highly-used open source project.
Why? Try explaining the rules of English spelling or grammar to someone. It requires many special cases, exceptions, and exceptions to the exceptions. Business processes are, sadly, the same way.
Should you refactor? Of course, when doing so allows faster fixing of bugs or adding new features (i.e., when it makes it easier to make the code more functionally complex.)
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Re:Joel on Software explained it in 2000 (Score:4, Interesting)
I suspect this is a message intended to those starting out to do something weird rather than accumulated complexity over time.
I have seen some pretty stupid stuff. For example, a development team came to me for help because some operation was slow. Turned out they had written their own file copy routine instead of using the standard library, and they manually copied stuff in and out of a 512 byte buffer. There was no good reason for this, no possible good reason, but for whatever reason they wrote a bespoke function to copy a file from one place to another despite the standard library having that built in. Replacing calls to that with the standard library sped up the operation over a hundred fold.
Now that said, sometimes 'complexity' is invoking "frameworks" too liberally, and trying to use them for things they were never really geared to do. So you have a framework that strives to be a streamlined facility for a GUI wrapped around a SQL database, and that framework is popular so someone declares 'lo, we shall use framework X', except there's no SQL database in the particular scenario and thus it really doesn't make sense and you end up doing all kinds of weird things to circumvent the natural design point of SQL at the core of the given framework. The framework was designed to make exactly one thing easy, and you aren't doing that, yet you still try to use the framework anyway.
Like all sorts of this guidance, everyone can find a way to agree or disagree depending on how they interpret it.
Re: (Score:2)
Try explaining the rules of English spelling or grammar to someone. It requires many special cases, exceptions, and exceptions to the exceptions.
You mean ear and bear aren't pronounced the same? Where does tear fit into the picture? Can we try food, book, and good?
Re: (Score:2)
Yeah, agreeing with the other poster: this is not what TFA is talking about.
Vibe code it (Score:2)
dude, just feel the vibes.
Software should be "simple and disposable ... (Score:5, Interesting)
Really? No. This is just writers filling up blank space.
If software is working and provides the functionality you need, then why would you dispose of it?
If your software does anything useful, you modify rather then dispose of. There are obviously limits in reality, spaghetti code does develop over the lifetime of modifications.
If you have a complex problem to solve, then your solution must address that complexity. Simple and complex are opposites.
If you simplify, then by definition, you reduce complexity. You can't really simplify things very much. Ex. if you use Wireshark, you still need to understand Internet Protocol. Some people consider Wireshark easier to use than tcpdump, but if you don't understand the data/protocol, you won't be able to use either. Wireshark is a gui. Does that actually simplify anything?
Everybody would like to have simple answers to complex questions, but that can't happen without the loss of information.
Easy to change? Would be nice, but reality usually ends up in the spaghetti zone.
IMO, you'd only dispose of software, most likely, because you vibe generated it, and it's so brittle you can't change it.... or in a more legitimate scenario, you developed a prototype to prove a concept. Concept got proven, then you set out on an actual design.
Re: (Score:3)
> If you have a complex problem to solve, then your solution must address that complexity. Simple and complex are opposites.
> Everybody would like to have simple answers to complex questions, but that can't happen without the loss of information.
Important points to live by, not just for software. The drive to find simple solutions to complex problems rather than accepting and managing complexity causes a lot of harm and waste.
Re: (Score:1)
I agree. The Einstein quote applies: "Everything should be made as simple as possible, but not simpler".
Whether a GUI or CLI is easier for you depends on your history. Either way, your code is implicitly hiding something , otherwise the user/programmer would just be using the "bare metal" your code is built on.
Make sure what your code hides isn't something your user needs to see, that they can easily see and change anything they may need to. I'm suddenly feeling the urge to expound on how, but I think tha
It's not the complexity with cathedrals (Score:2)
It's the time need to be completed.
Cologne Cathedral, 632 years
St. Vitus Cathedral, 585 years
Rouen Cathedral, ~678 years (with long pauses)
Milan Cathedral, ~579 years
Ulm Minster, 513 years
Strasbourg Cathedral, 424 years
Notre-Dame de Paris, 182 years
York Minster, 252 years
Seville Cathedral, 106 years
Sagrada Família, 143+ years (ongoing)
Writing simpler systems is harder (Score:2)
Anybody can just throw more code at any problem and eventually fail. Making things simple but functional is a lot harder and not many people can do it. But if there is one thing to learn from engineering history, it is that simple solutions are always fundamentally better than complex ones. Of course, depending on the problem, there is a lower minimum complexity that you cannot go below. But any good engineer will always try to get close to than boundaries. Unfortunately, there are a lot of bad and mediocre
Stop Writing Cathedrals of Complexity (Score:4, Funny)
and Start Writing Bazaars of Improvisation ;-)
Years later... (Score:1)
Stuff I write tends to hang around for years and sometime decades. There's a water vending machine that I wrote almost 40 years ago now and it's still running just like it always did, though the hardware and even the shack by the side of the road that it lives in has changed a few times over the years.
I've found that when I have a brainstorm and write some "clever" code it tends to turn around and bite me when I come back to it ten years later to make a change. Either because I can't remember why it's doi
There is no greater code smell... (Score:2, Troll)
...Than using Ruby on Rails.
+37 Insightful (Score:1)
Ruby On Rails smells like a self-documenting Dumpster.
(Choice of "+37" intentional)
Re: There is no greater code smell... (Score:3)
Clearly you've never had to deal with the stygian horror that is modern web code with an unholy mix of html, style sheets , javascript with multiple offsite libraries in the browser, and whatever dogs dinner combination that runs the backend.
If you're not using 256 JS lib for a simple form.. (Score:4)
...you must suck! I mean what kind of shit-gibbon-amateur just writes forms? They're not responsive, angular, or reactive!!!! Only amateurs would let a tiny form page load in less than 10 seconds.