Are Technical Best Practices Cyclical (like fashion)?
I have generally viewed technology best practices, especially around how software is built and deployed, to be on a progressive line, getting better as we move forward. I have seen a similarity to building construction technology, which has steadily improved over time to allow us to build bigger, safer, longer-lasting, and more designed buildings, from the thick walls of the medieval period to the flying buttresses of the Gothic period to the steel framing of skyscrapers.
However, I was recently challenged in my view, with a counter hypothesis that, in technology, “everything old is new again”, and that things go in and out of popularity in technical best practices, like fashion. And while I think there is some truth to this as far as consumer electronics and startup investments (e.g., take this Techcrunch article), I personally think I have continually improved how well I (and my teams) build software over the past 25 years. But, always up for an opportunity to be introspective, I thought this challenge worthy of investigation.
If It’s Not Cyclical, Where Have We Been Going?
In order to understand why I don’t think that technical best practices around building and deploying software have been cyclical, it makes the most sense for me to explain what I think the overall trend is. In the next section, I will address specific examples that might be given to argue for cyclicality.
I think there are several overall trends that have driven best practices, and that it’s quite easy to see where we are going in the future simply by understanding how we’ve gotten to where we are today:
- The rise of software: essentially every growing (or at least not shrinking) organization has become more and more dependent upon using software in order to be more efficient and more effective.
- The rise of the Internet: essentially every growing organization has similarly found that the Internet — and, in particular, high-speed, always-on, unlimited-bandwidth connections to the Internet — has dramatically improved corporate and employee efficiency.
- The rise of delivery of services over the Internet: growing organizations have found that where services can be delivered via software-as-a-service (SaaS) over the public Internet, it almost always makes sense to deliver them that way, as customers prefer it, and it’s much cheaper and easier to provide a better and more consistent experience. This has accelerated even more with the growth of smartphones, through which you can increasingly reach anyone at any time with a rich user experience
Said another way: Software is eating the world and growing organizations are the ones that are finding ways to effectively deliver software (usually SaaS) to customers. Everyone else is dying.
If you accept the above three major drivers, then we should expect to see best practices embrace whatever technologies existed at a particular point in time to enable organizations to get the maximal benefits from software. We will naturally see changes over time as various technologies become available and affordable (e.g., desktop computers, the Internet, smartphones), but we shouldn’t see any backwards embrace of a best practice that has fallen out of favor.
Arguments for Cyclical Best Practices
Let’s discuss examples that can be suggested as supporting the argumentthat technical best practices are cyclical.
“The Cloud” is a cyclical return to centralized computing after a detour to client-server
Many of the infrastructure-as-a-service (IaaS) critics from 5 or so years back argued that it was just a return to the computer bureaus of the 1960s, or other methods used primarily between the 1960s and early 1990s where mainframes used operating systems with task switchers and schedulers (e.g., Unix) to allow many users to run applications on a single piece of hardware that was maintained by someone other than the user. With these setups, users had “dumb terminals” that could only connect to the centralized server and all code was executed on that centralized server, with input coming from the dumb terminal and output being displayed on the dumb terminal.
The rise of the personal, desktop computer brought with it the client-server architecture of running a server (often just a database) centrally, and having each individual user have their own computer and client applications (“thick clients”, because the code runs on the client machine) that connected to the server. (And the simplest/original version of this was to just have the client be the server, like how Act! and Quickbooks and Access were designed).
Organizations embraced this change over mainframes + dumb terminals for two main reasons: (a) much cheaper to start, (b) easier to train employees to use the more graphical applications that could be rendered on desktop computers than on dumb terminals (DOS’s ANSI support blew away the TTY graphical options from mainframes, and then windowing OSes went even farther; Unix’s XWindows was too little, too late).
Companies building software also embraced the client-server movement because it made it much easier to deploy their software to customers, and they could customize user experiences much more, because the desktop computers had many more graphical (and other) options. Instead of having to deal with centralized gatekeepers for deployment, one only had to sell a diskette or CD to a customer, and that customer could install the software directly.
The rise of the Internet brought with it the concept of SaaS (although that term was coined roughly ten years after broad availability of at least dial-up Internet connectivity for most Americans): instead of running software locally on your computer, you could go to a web page, which was (initially) somewhat dumb-terminal-like: a web server would spit out HTML (and later CSS and Javascript), and your web browser would render that into (originally) a static page. You could type things into form fields and click buttons and images, all of which would send a request (again, somewhat dumb-terminal-like) to the web server, which would do some computation and return HTML back to the browser (again, somewhat familiar to mainframe-dumb terminals).
However, to the people building software, SaaS was nothing like the mainframe-dumb terminal days of old, where the software providers were at the mercy of the mainframe admins and the limitations of those mainframes. Instead, SaaS was more like delivering on diskette/CD/download, except that in some ways, SaaS was better: it dramatically reduced costs (no media! no super-expensive QA before releases!) and made for a much better end-user product (releases much more frequently!). In some other ways, though, SaaS (initially) was worse: the limitations of HTML (and then HTML+CSS+early Javascript) were very obvious when compared against a thick desktop application. And so many people had unreliable Internet connections at first that SaaS felt inappropriate for many use cases and many customers, especially around early mobile computing.
And we now live in another rise of thick-client applications. As I explain in an article I wrote more than two years ago:
But then the iPhone came along, and it became clear that mobile apps would be a big thing, leading many to declare applications should be build “mobile first.” The user experience of mobile apps was superior to the mobile web in many cases, so companies realized to reach customers most effectively they would need apps. Additionally, the capabilities of client web browsers improved significantly, allowing for much better browser-based user experiences with “single-page applications” (SPAs) that used Javascript to make the browser work much like a thick client-side application.
But this change is much smaller to software developers than the move to SaaS (or the original move from mainframe software to desktop software). In many cases, the hosting, development, and delivery of software to SPAs looks almost identical to “thin-client” SaaS delivery. And even though having to build native apps for iOS and Android, as well as building SPAs that have to test out in four major browsers, is not pain-free, it’s still a lot less painful than having to build for multiple desktop platforms with QA processes that can certify gold masters.
The move from mainframe to client-server to simple SaaS to the new thick client SaaS is best understood from the perspective of the software developer, and the steps have been toward making it easier to deliver a better customer experience at lower cost. There’s nothing cyclical about it.
Software developers used to work by connecting to mainframes and writing code on that server remotely, then they went to Visual Basic and other Rapid Application Development software toolkits that were very WYSIWYG. Then we had a return to scripting in terminals, connected remotely to cloud virtual machines.
To understand these software development practices over the past 50 years, it’s useful to think about how software interfaces have changed over that time period. At a very high level, software has gone from being purely text, to being graphical and interactive but in ways that software developers themselves could manage, to being graphical and interactive in ways that require skills that the vast majority of developers do not have.
Developer tooling and practice has followed this trend around interfaces. Initially, everything was text, so all development tools were in text. In the brief period of ANSI menus and ugly/corporate client-server applications, developers could do all the design work, so developers made development tools for other developers that allowed these types of simplistic GUI designs (e.g., Microsoft Visual Basic, Borland Delphi; and even before those, Hypercard). These types of tools were very limited (designers today wouldn’t use them for all of the painful limits), but they allowed developers to build reasonable graphical interfaces.
But as soon as we moved to wanting designers on all applications (not just games), the way that development needed to happen changed. Developers needed to support the designers and implement the designs, but could go back to the most efficient workflows for developers, which involves writing precise, specific instructions — in other words, text in text editors. (Modern design practice for SPAs is probably the best example of this: designers build in a graphical design application like Sketch, and developers write lines of CSS to implement every shape/item in the layouts).
Another movement we’ve seen is that developers like to develop in environments that are identical to production, to minimize the number of issues that come up when deploying code (“works on my machine!”). So this meant developing on mainframes when they were the production target; on their own desktops when those were the target; and on remote virtual machines when those were the target. Modern DevOps, much of the deployment tooling that we have around our continuous integration systems, as well as containers now allow us to develop on our local machine in an environment that is essentially guaranteed to be the same as the the production environment, so we are seeing more and more of a return to local development. (And this is especially true with SPAs [where the actual code runs in the browser on the client] and with modern source control [where you don’t want to be working on the exact same copy of the code as other developers]).
The Forest and the Trees
I do think it’s possible to look at certain aspects of software and software delivery and feel like it’s cyclical, but I think upon reflection, that is much more the trees than the forest. The software we deliver today is much better from a user experience standpoint and delivered much more effectively than it ever has been. And just as we essentially never see users digging out older software because it was better, we also don’t see growing markets for mainframes in parallel with the public cloud. And we march onward!
