|
|
posted: March 2, 2019
tl;dr: It used to be impossible or very expensive, now this feature can be easy if you set things up right...
The first and most important feature to put into any software product is not user authentication, in-app purchase, cart checkout, the database, or the user interface. It is the ability to upgrade the software.
A software product that consisted solely of a software upgrade feature wouldn’t have enough functionality to be a Minimum Viable Product (MVP), but it could be bootstrapped into an MVP. A good software upgrade process can allow an MVP to more easily accrue new features and grow into a product that addresses more of the market. It can also minimize the impact of defects and save the company money and goodwill, by making it possible to quickly roll out fixes. All these reasons are why, at each of my employers, I’ve taken an active interest in the software deployment and upgrade process. One command or one click deploy is always the goal.
It wasn’t always this easy to upgrade a user’s software: in the pre-mass-market-Internet days, it could be expensive or impossible. I worked on one such product in the 1989 to 1991 timeframe at a startup company called AT&E, which developed a wristwatch pager in partnership with Seiko. The watch had a microcontroller with software stored on-chip in Read-Only Memory (ROM). The hardware didn’t support reprogramming; even if it did, we would have had to re-architect the packet radio transmission network in order to send out software updates over-the-air.
So when it came time to ship the software for the first production run of 10,000 watches, which had a manufacturing cost of close to $100/each, we knew we were making a million dollar decision, in 1990 dollars. We could change the software for the next production run, but those first 10,000 watches would always have the software release we sent into the factory for the first major manufacturing run. If the software had some sort of major bug that impacted users, the watches would have to be discarded, possibly after they had been purchased, which would necessitate a recall program.
In the shrink-wrapped software days, a software release could cost millions of dollars
A similar problem existed in the personal computer (PC) software industry in the 1990s. PC software was typically sold at retail in shrink-wrapped boxes, which contained a user manual and other paperwork plus the software on either floppy disks (in earlier days) or Compact Discs. For high volume mass market software such as Microsoft’s Windows 95 operating system release, the company manufactured millions of shrink-wrapped boxes. To get comfortable with betting millions of dollars on a software release, both the startup I worked at and Microsoft followed the same basic process: test, and test, and test, for months, until you finally are confident in the software.
My next employer, ADC Kentrox, had several networking device product lines for high-speed private networks and Internet connectivity. Because the products inherently were connected to a high-speed network, we were able to build a software update feature by designing the hardware to contain two banks of reprogrammable read-only memory (predecessor technologies to today’s flash memory). Life got better for us, as we didn’t need to worry about losing millions of dollars due to a bad software release. Upgrading software over the Internet ultimately spread to pretty much all client-side devices and software products. Today users are barraged with software upgrade messages from their computers, smartphones, tablets, smart TVs, and other devices.
In the web application world, the client-side software (HTML, CSS, and JavaScript) is effectively shipped to the user in real-time as the user operates the browser. A user doesn’t have to take any action to upgrade their client-side software, aside from an occasional browser cache clearing. The software gets upgraded entirely under the control of the company which developed the web application, by deploying new software to the servers in the Web which host the web application. Upgrading the web application for all users can be as simple as one command or one click, if there is a good pipeline in place to build, test, and deploy the code.
The software upgrade process has evolved over the years from having to have a device entirely replaced, to going to the store for new software on physical media, to Internet-delivered software upgrades, to just opening a browser tab to launch a web application. Web applications deliver software upgrades to users without them having to take any action. There is a downside, however: the users often do not even realize their web application has been upgraded until they are using it and stumble upon a new button, menu item, or screen layout, which can confuse them. With great power comes great responsibility: companies developing web applications need to be careful to introduce new features in ways that cause minimal user confusion and angst.
Related post: Software that shouldn’t be fixed