Here is another old draft, apparently made on April 4, 2013. The title is a reference to a Honda advertisement, titled ‘The Cog’:
At this point it is clear that the title was a draft: I wrote down the title and the note ‘Honda ad’. The ad actually says “Isn’t it nice when things just… work?”, so I apparently misremembered it, and didn’t look up the ad at the time when I wrote down the draft.
By the way, this is what is known as a ‘Rube Goldberg machine‘: an overly complex contraption to perform a seemingly simple task.
The ‘Honda ad’ note was followed by a short quote from an IRC chat on #Win32ASM, which included a link to a Slashdot post that talked about Google forking WebKit: http://tech.slashdot.org/story/13/04/03/2125246/blink-google-is-forking-webkit
I responded to that article with the following quote:
Gotta love the 80s… “This is your machine. Shit works”
I guess people today didn’t grow up that way, so they don’t understand
the concept of working shit
There is a blog in there somewhere
Well, the time for writing that blog has finally come. I suppose the problem here is that this small idea was the only note I had made, and that’s not a lot to write a whole blog on. It’s also interesting that a lot has changed since I made that note. It is now 2022, and virtually all browsers are now based on Chromium/WebKit. Which also means that the few who aren’t (mainly Firefox), need to try and keep close to Chromium/WebKit in terms of compatibility, as that is the de facto standard. That’s a huge improvement from the old days of web technology, where you had to have a lot of browser-specific code to handle all the differences between the various browsers (such as Internet Explorer, Edge, Chrome, Opera, Firefox and Safari).
I suppose I also recently made some remarks about other downsides of web/browser technology, in my downgrading blogs regarding CefSharp: development of both browsers and websites goes very fast, so a browser is quickly outdated, and no longer able to render even a basic home page for Google, Microsoft or such.
But to be fair, forward and backward compatibility was not a particularly strong point of most platforms in the 80s. The IBM PC was the exception to the rule. If you look at Commodore, you couldn’t just run software written on a PET on your VIC 20, and the C64 was also not compatible with either. The C128 may have had a C64 mode, but the Amiga again was not compatible with anything prior.
Another point I would like to make, which I guess is more fitting for 80s platforms: having reliable software and configurations. Granted, software may have been simpler in those days, but that should be no excuse to make a mess of things. In those days, software just ran out-of-the-box, and you didn’t have to worry about whether your hardware was compatible, whether you had the right drivers and third-party tools installed and whatnot… and whether a missing or incorrect configuration file prevents you from even running the application.
In the current day and age, sure, it’s more difficult to get software running, since there’s less you can assume about a platform. But that should be no excuse not to even try. Ever since the late 80s, software came with installer/setup tools which tried to make sure your system could run the application, by checking the system requirements, and making sure all the required drivers and third-party libraries are installed.
And if you’re a developer, this philosophy should also hold for your source code: when you check out the code from a repository, you should be able to build it as-is. All the required dependencies should be included, and if any libraries or tools need to be registered, installed or whatnot, ideally that should also be part of the build process, or at least, they should be included with the checkout, with a readme to tell you how to set up your system to build the code.
With regular consumer-oriented software, it’s not usually that bad, but I’ve worked at various companies that made client-specific solutions, and there it was quite common that you couldn’t just ‘turn the key’ and even get a basic instance of an application up. No, you had to have a configuration file. And not only that, you had to know exactly what to put in that configuration file, as some kind of magic incantations. Otherwise, the application wouldn’t start. And it wouldn’t just tell you where the problem was, no, it would just generate random exceptions, based on what exactly was missing on wrong in your configuration file.
I think you should try to develop every application along at least these two basic rules:
- The application will start, even with a missing, broken, or incomplete configuration file. The application will use sensible defaults where possible, and should decouple configuration data from the actual logic. So you should just run the application, and then expect a certain variable to be set based on the configuration file. You should set a sensible default value, and if that is not possible, you should do a sanity check, and tell the user what value is missing, and should be set.
- Your configuration file should be documented. For example, if you use XML, you should have an XSD that tells you exactly what settings there are in your configuration file, and what possible values you can use. With modern tools, you can actually generate serialization/deserialization code based on an XSD, so your XSD can be leading for the actual code you use. Ideally you should have the option to let your application write out a full configuration file with all the possible options, so you can easily read and modify it by hand.
It is just so much easier to be able to start an application, even if it is in a wrong/limited configuration. When you can at least see things on screen, and get an idea of what is not working the way you expect. It also makes debugging easier in most cases, as you can poke around in the application, and not get caught up in some unhandled exception before half the application is even loaded.
So in that sense, things should “just work” when you start the application.
Scali's OpenBlog™ 