LinLog

Here's a talk Rasmus recently did on 25 years of working on PHP.  I found it interesting and entertaining.

One of the things I thought was really interesting was the explanation for many of the more hair-brained features of PHP.  It's all the same explanation - for most of it's history, Rasmus was operating under the assumption that PHP was about six months from being out-dated and replaced.  

This is interesting to me because it's the sort of thing that most developers can relate to.  In retrospect, it's obvious that features like safe_mode were a bad idea.  But on the other hand, if you think that your language is going to be replaced "soon", then it kind of makes sense as a quick-fix for a serious issue.

To me, this speaks to the trade-off between "always do it right" and "just do what you need to".  You often hear the latter perspective from the agile methods camp.  For instance, it's the motivating idea behind the "minimum viable product", i.e. that you should build the smallest thing that remotely even remotely fits the requirements, even if you know you're going to immediately throw it away, because "hey, you never know if it'll be good enough".  But then the software craftsmanship camp, which is kind of related to the agile one, often give the opposite advice, that you should "always do it right, because it might be good enough to go to production."

I had this conundrum in a previous job.  We were building a system to integrate 3D models of building interiors with 360-degree internal panoramic images and and external aerial imagery.  The general idea was that you could explore the interior of a building as well as look at the surroundings using oblique and orthogonal images, as well as orthomosaic imagery.  It was actually a pretty cool system, and we built a nice, unified web interface that allowed you to transition seamlessly between the various views.

That's all well and good, but there was a problem: the contract with the customer called for an offline version of the system.  This was a major issue, because the application was leveraging our existing technology (which was online-only) for the external imagery.  So we were faced with the prospect of taking our existing online infrastructure, which was based on PostgreSQL and PHP, and somehow turning that into a stand-alone offline application.  In the best-case scenario, this seemed like a big pain in the neck in terms of packaging and maintenance.  In the worst case, it could be a massive time and resource sink.

Neither I nor the other senior engineer on the team were enthusiastic about this.  I mean, it's a lot of work and there was no clear use-case for it.  In fact, the only reason we were doing it was because the contract said we had to.  So what did we do?  We cheated and went with the "minimum viable product" solution.  We knew that, either way, we'd only be able to include a limited set of external imagery, so we took advantage of that fact.  Rather than repackage the entire web-based system for offline use, we pre-calculated every possible AJAX call that the web page could make.  It was a decent number of calls, but completely unreasonable.  That allowed us to just ship the front-end (wrapped up in NW.js) with a bunch of JSON files and a little bit of custom mapper logic to map the standard AJAX calls to the pre-calculated JSON responses.

And you know what?  It worked just fine.  It met the requirements and held up our part of the contract.  It might not have been the "right way" to do it, but it worked.  And last I knew, there were no complaints from the customer and no interest in an offline solution from any other customer, which vindicates our choice of a "cheat" solution.

Of course, if we wanted to have a really flexible, powerful solution that we could extend in the future, we would have done it "right".  But in this case, we kinda figured that this project wasn't going anyplace long-term, so we went with the easy fix - just like Rasmus.  So while I'm still annoyed by some of his early choices, his explanation gives me a little context and some sympathy for his thought process.