Getting it done by not doing a lot of it
by Cal Paterson
I didn't write any frontend form validation. No need - that can all be done with HTML5.
I didn't write a date picker. Again, HTML5.
The HTML on my pages is generated by templates, as if it were still 2005.
Forms are submitted using
multipart/form-encoding, again, as was done by my
forefathers, before the advent of
When a form is "editable" (ie you get some kind of plus button that dynamically adds another form field) I just have that plus button add a query param and use HTTP GET to get a new version of the form with that field added (the minus button does the reverse). Again, HTML5 allows you to give individual buttons a special "formaction" and makes this trick easier than it used to be.
Sticklers will contend that in fact there is a
.js file that came with the
CSS framework I used. It's true - but I didn't write that file. I
don't even read it. It is completely encapsulated as far as I am concerned.
One way to predict car reliability is by the number of parts. Cars with a higher part count tend to be less reliable, because as a car gets more complicated there are necessarily more ways things can go wrong. If you do have a part, best that it not be a moving one. Interior trim pieces rarely cause trips to the mechanic. If your mechanic mentions your gearbox however, you are about to hear quite bad news. All else being equal: fewer parts are better.
The runtime of the whole testsuite is 3.5 seconds - without parallelism. That's about 10 milliseconds per test. I should mention that I don't mock out the database. As csvbase is sort-of an ORM so the loss of correctness would not be worth the increase in speed. Some of the queries can get quite complicated.
The upshot of all of this is saving time. There is an old joke that if any government programme fails, it was because the budget wasn't big enough (and that if it succeeds, well; that only proves the need for even more budget). The analogue of this joke for software projects would certainly refer to time instead of money.
Working software takes a stunning large amount of time to make. How can you make time for your side project?
Nowadays there is a vast and growing "productivity industrial complex" - thousands of podcasters and bloggers advising how to reorganise your life in order to save time, or at least use it more efficiently. To be honest, I never felt kin with them.
Just as money is not really the problem with most government programmes, for software projects, time only feels operative because of issues in other areas. I've always felt that the path to getting something out the bleeding door is less about being supernally efficient and/or "effective" than on finding the right shortcuts that make it possible, in any reasonable amount of time.
This isn't to do down the Facebook Reacts of the world. They have a place, but the occupational hazard of professional programmers is the feeling that if you do something in your day job then you can bring your skills home and use them to do your own project on the side. The problem is that you also bring home the mentality. Your workplace's standard practices are probably an order of magnitude or two more labour intensive than what you can afford given that you are, eg (as in my case), hacking on the project only while your toddler is sleeping.
I have always been interested in why so many successful companies/organisations started with LAMP and, specifically: PHP.
Wikipedia, Flickr, Facebook, Slack and Wordpress all used PHP (originally...). What is it about PHP? I don't know PHP well at all but from the outside, it looks to me, an obsessive shortcut-taker, that PHP absolutely conspires to provide shortcuts.
Serious projects build distribution packages (somewhat complex, 5mb), docker containers (secretly very complex, 100s-1000s of megs) or unikernel things (who knows how complex, loadsa megs). I have worked even in smallish companies where it is multiple people's fulltime job to deploy code to production. By contrast, many PHP applications are copied by FTP client straight into prod.
I mentioned above that package management, depressingly, can be quite a hard problem. PHP now has package manager, but, in the golden era, people simply copied files they wanted to use into their project. (C programming still works the same way - for appearances' sake this 'technique' is called "vendoring").
This is not all to say that I think PHP is some kind of latent ideal language. I didn't write any PHP for csvbase. But I do think there is something to learn from PHP culture. Shortcuts are important. One of the fitness functions for ideas is whether anyone can release a version 1.
That means that there is a scale where deployment-via-FileZilla is appropriate: the scale of a small project. 'Small' is an important scale because while not every project becomes large, every project starts out as small.
Please do send me an email about this article, especially if you disagreed with it.
I am also on Mastodon: @email@example.com.
Follow new posts via RSS.