Title: Why I Avoid PHP

Author: Bob Schmidt

Date: 05 September 2017 16:21:49 +01:00 or Tue, 05 September 2017 16:21:49 +01:00

Summary: Silas S. Brown shares a war story.

Body: 

Readers of the CVu ‘Members’ column will notice that for some time ACCU has been seeking a volunteer to update a website that was done in Xaraya, a PHP framework. This has reminded me of my own (negative) experience of a project using the language. My experience has made me wary of volunteering even though I have no reason to believe I would encounter similar issues. I’m writing this, not to put anybody off, but as a starting point for discussion. Is there something wrong with my attitude? Have you had experiences – bad or good – with a language outside its technical aspects that have affected your willingness to use it again? (This article also has some relevance to Francis Glassborow’s article in CVu 29.3, asking us to discuss other languages, although I fear it’s not the type of response he wanted.)

I have some friends who started small businesses. One of them wanted a website (with a database and various bits of business logic and so on), and outsourced it to an offshore development company. They implemented it using Laravel (a PHP framework). My friend then said they weren’t happy with the result and needed it to be fixed in a week. And said could they pay me to look at it, as I’m supposedly a good Computer Scientist and PHP is supposedly an ‘easy’ language, so surely I could fix it in a week, couldn’t I?

I said I’ll take a look. Someone at that company showed me some of the source code on his laptop. It seemed to have meaningful variable names and to be reasonably formatted, so I said it looks good so far, but I’ll need to browse the whole thing myself. Could I sign an NDA they said. Which I did (as, in my experience, if you have to sign a non-disclosure agreement to see something, then the chances are it’s not going to be high-quality enough for disclosure to be desirable in any case), and then they gave me the root password to the virtual machine they were hosting it on.

So I started reading through it (I always like to look through any new codebase, to see what’s where), and reading through it, and reading through it, and.... And then I had the bright idea of doing a line count. 830,000 lines of PHP, 81,000 lines of CSS, and nearly 300,000 lines of Javascript.

I was shocked. How could I even finish reading this thing on time, let alone making changes? And how did a simple small-business website become 1.2 million lines of code?

Well I could see how the CSS blew up. I thought ‘responsive Web design’ was supposed to mean using sensible CSS rules to specify how the elements on a page are positioned with respect to one another, using measurements relative to the font and screen size but without depending on exact numbers of pixels. I didn’t think it meant ‘create 52 particular screen sizes and apply a separate set of pixel-driven stylesheet rules to each, with lots of duplicate code’. Oh and some of the CSS and Javascript was ‘minimised’ (i.e. obfuscated) so it wasn’t at all easy to debug.

So the first thing I did was to disable 51 out of the 52 screen sizes, and improve the remaining rules so that they worked properly without having to special-case anything (I think that’s called ‘fluid design’). But then they complained I was breaking more than I was fixing, and no wonder: there was far too much coupling between the CSS, the Javascript, and the PHP; I couldn’t just change something and expect nothing else to break.

I don’t know which version of Laravel they had used. It certainly wasn’t the latest version, and the latest Laravel documentation didn’t help me. Of course the company had no idea what the outsourcers had done, and the outsourcers were no longer available for questioning. And nobody had thought to save a copy of the documentation that corresponded to the old version of Laravel in use, or at least make a note of which version that was. Comments had been removed and things had been customised. And the more I tried to make sense of the code, the less sense it made: I kept finding components that seemed to be completely irrelevant. Does that outsourcing team simply dump their entire code-base into every project, switching parts of it on and off as necessary? And yet I couldn’t find any obvious place I could use as a starting point to tell me which parts of the code were actually relevant. Did they use some kind of front-end or IDE to edit all this? I only had Emacs. They wouldn’t tell me what else to use.

When I voiced my complaints, their first reaction was ‘we do things differently in our country’, as if I’m a bigot to say a design is bad when it just happens to have been made in a different country. (Should I go out of my way to find that country’s top designers and ask them to back me up? Or find a few examples of bad design from my own country just to make it even?)

“Why can’t you just change the layout?” they said. Surely it’s as simple as that isn’t it: just change the layout. You’re a computer scientist, remember? This should be easy for you.

I sent them the words of Rupert Gould, as portrayed by Jeremy Irons in Charles Sturridge’s 1999/2000 television adaptation of Longitude, when Gould was trying to restore John Harrison’s early prototype maritime clock:

I’m going crazy! No don’t worry, not that crazy. It’s this machine. There’s not a straight line in it. It’s layer upon layer of corrections, each one fitting on top of the other. Whenever he came across a problem, instead of going back to the beginning, he’d add another level of complexity. Springs, working against levers, working against other springs and other levers, it’s madness! This man is born of a refusal to be wrong! He couldn’t just say “I’ve made a mistake”; he’d say, “I’ll add something else and then it won’t BE a mistake.”

(If you want to find that scene, try looking just before the 30-minute mark, but there might be differences between the original UK release and the cut-down US one. I’d like to be able to show the clip on demand in any conversation. I wonder if the scriptwriters realised how salient that scene is for some software-development situations.)

Still they kept insisting that I was a good enough computer scientist to be able to fix it easily. I was tempted to say “OK, I’m not really a computer scientist, all my qualifications are fake” just to get out of that. I suggested they let me re-write the whole thing from scratch to an internal design that I can understand. They said I wouldn’t be able to do a rewrite in time. I said that’s probably true, but the chances of being able to do a rewrite in time are actually greater than the chances of being able to fix the original in time. They didn’t buy it.

And then I realised I did actually have a trick up my sleeve. My Web Adjuster! Never mind trying to fix the PHP: just bolt my Web Adjuster on the front, and set it to make all the changes the company wanted as regular-expression substitutions on the HTML and CSS going out to the browser. Yes it would make me guilty of ‘adding another level of complexity’ myself, but it would at least buy time and then I could suggest a rewrite later.

But then I made the mistake of making certain substitutions global instead of restricting them to particular pages, and that meant they had unwanted side-effects across the rest of the site, reinforcing the idea that I was creating more problems than I was solving. That would have been a simple change to fix, but they said “forget it – we’ve had a meeting and decided to abandon the launch, and we’re getting a UK company to rewrite it in Wordpress”. They were nice enough to pay me something anyway, although it was only about 35% of what they’d originally said. (I said OK, although just to prove a point I did then put in the fix for that ‘last straw’ problem. Their style of management involved looking at ‘how many pages you’ve got through so far’, which didn’t particularly help them understand the concept of a global change.)

This has all left me with a rather bad impression of PHP. While I’m sure it is indeed possible to write beautiful code in PHP, it seems the barrier to entry is so low that much (perhaps most?) existing production PHP code is bloated, badly-designed beginners’ ‘cruft’ that shouldn’t be anywhere near a serious commercial business. That means there’s a high probability that fixing an existing PHP project will be frustrating, and I certainly can’t recommend the idea to students who want marketable experience, since I wouldn’t wish a PHP career on my worst enemy. Perhaps Rasmus Lerdorf could tell me why it’s not his language itself that’s the problem, but the codebase? Just don’t go there.

Notes: 

More fields may be available via dynamicdata ..