ArantorApologies for the title. The title sucks, but it does reflect how I feel.
I’ve done my share of dabbling in various things over the years – PHP is where I’ve made my home, and I’ve tried several of the big frameworks (and some of the smaller ones) over the years. I’ve also played around with Django and Twisted over in Python land, bits and pieces of Goa in Go, and a whole bunch of other environments that don’t even really have frameworks.
Now, professionally, I do the ol’ day job in PHP, and in a small design studio, there are only really two choices if we’re in the PHP ecosystem: WordPress for a CMS and Laravel for anything heavier. This is not to say that other options don’t exist, they do, I know they do, even in PHP land, but the reality is the customer doesn’t care. Half our Laravel folks come to us because we say outright ‘we do Laravel’.
Not that we wouldn’t do Symfony or Zend/Laminas or Yii or (showing my age) CakePHP or CodeIgniter if we were asked, but we probably wouldn’t in practice. I’ve done stuff in all of these professionally over the years. Would even, probably, do again if asked.
But from a business perspective, standing up a sustainable development project… going with anything other than a framework would be madness. No-one is going to fund a completely greenfield development unless literally none of the existing frameworks suit the bill – in which case your problem is that you’re using the wrong tool for the job on a fundamental level.
Here’s where it gets interesting. I spent a not-inconsiderable amount of time approaching an older PHP platform, teasing it apart from all the ‘bad’ ways. The global variables that were almost highly-mutable singletons. The non-conformance to a single entry/exit point for the purposes of PSR-7 conformance. No dependency inversion, minimal inversion of control, improper separation of models and controllers. And I spent many, many hours trying to retrofit those things in. I didn’t finish because after those many, many hours all I got for it was that everything was slower and clunkier.
Which got me thinking about a post I saw recently on Reddit, entitled Laravel considered harmful. It’s quite a deep technical post, and I could spend far longer than this post deconstructing it in exquisite depth but no-one really has time for that.
What it comes down to, though, is really the central thesis for this post. Do we need frameworks? Moreover, should we use frameworks in every project where one even halfway suitable exists?
In my work life, this is a complete no-brainer, the dev cost of rebuilding the framework layer far outweighs the business cost of using a framework and just papering over the higher resource utilisation – CPU time is cheaper than programmer time.
But for my hobby projects? That’s a different equation; I do what I do for the joy of doing it, for the most part, and I don’t need a framework when I might be building an application. But there’s a deeper component: at least one of the projects I have in mind for the near future has a scalability component to it, it’s not that it’s not designed to scale, but it’s notionally got some requirements to run lightweight on commodity servers and consume less CPU time than its effective rivals, noting certain tradeoffs in so doing.
Which then got me thinking about all the other architectural things. Right now, in 2023, any new project that isn’t unit-tested, isn’t SOLID, isn’t all the ‘shiny things’ would be bashed halfway to the end of next week for not being these things.
And I have to ask: is it actually worth it to have these things? Sure, you can unit test things. But most of the unit tests I’ve ever seen don’t test the logic, they test the environment around the logic, and almost never test the logic itself. Worse, most of them only certify the happy path is the happy path, so many never bother to test unhappy paths as validation that unhappy paths are indeed unhappy.
And of course when you write new functionality you have to rewrite the related tests so it becomes a drag factor. My question: does it actually get you anything?
I can see the uses of having a complete test suite ahead of a major restructure – to certify that the behaviour before and after are logically the same, but even that isn’t really true: the unit tests inevitably get rewritten with the restructure, so you don’t even really prove that.
And that’s before we get into the joys and woes of the more abstract stuff. Yes, a function probably should only do one thing. But some of the more… purist views, like a function should only be 10 lines max… that’s just dividing up functionality almost arbitrarily – sometimes a function is 100 lines of code, it’s fed its inputs, you get its outputs, and breaking it up doesn’t get you anything.
On a more anecdotal angle of the same, many years ago, I had a debate with one of the then-developers of the application I mentioned. She wanted to refit part of it to support using an external tool to perform a job, and I could see the argument for that. But she wanted to make it support several different ones, to ‘give developers the choice’… but as I outlined at the time, this made no sense. Sure, developers get to choose – but the people who actually use the application don’t care, they just want it to work, everything else is someone else’s problem. What would inevitably happen is that the developer ecosystem would gravitate towards whichever was default or easiest to do basic tasks in, and that would become the primary option – and anything else would wither and die unsupported, just burning whatever bridges were there with whoever did try to use those options. And my question came back to: what does it get you?
I suppose that’s really my takeaway here. We as an industry have been preaching for years for programmers to adopt these wisdoms. Now we’re at the point of often having done so, only for it to turn out that actually, applying them as truth rather than wisdom – the cargo cult at work – just reinforces that it never really mattered after all. We never asked what it got you.
I find myself questioning a lot of things that even a short space of time ago I’d have accepted as relative gospel. And yet, the more I think about it, the more things stay the same. But at least now I think I’ve learned that for any decision, I should remember to ask ‘what does it get me’ and if the answer isn’t favourable, try something else.
