The Next Big Thing

What will we see as the next big thing?

Let's look at the history of computer technology -- or rather, a carefully curated version of the history of computer technology.

The history of computing can be divided into eras: The mainframe era, the minicomputer era, the micro/PC era, and so forth. And, with careful editing, we can see that these eras have similar durations: about 15 years each.

Let's start with mainframe computers. We can say that it ran from 1950 to 1965. Mainframe computers were (and still are) large, expensive computers capable of significant processing. They are housed in rooms with climate control and dedicated power. Significantly, mainframe computers are used by people only indirectly. In the mainframe age, programmers submitted punch cards which contained source code; the cards were fed into the computer by an operator (one who was allowed in the computer room); the computer compiled the code and ran the program; output was usually on paper and delivered to the programmer some time later. Mainframe computers also ran batch jobs to read and process data (usually financial transactions). Data was often read from magnetic tape and output could be to magnetic tape (updated data) or paper (reports).

Minicomputers were popular from 1965 to 1980. Minicomputers took advantage of newer technology; they were smaller, less expensive, and most importantly, allowed for multiple users on terminals (either paper-based or CRT-based). The user experience for minicomputers was very different from the experience on mainframes. Hardware, operating systems, and programming languages let users interact with the computer in "real time"; one could type a command and get a response.

Microcomputers and Personal Computers (with text displays, and without networking) dominated from 1980 to 1995. It was the age of the Apple II and the IBM PC, computers that were small enough (and inexpensive enough) for an individual to own. They inherited the interactive experience of minicomputers, but the user was the owner and could change the computer at will. (The user could add memory, add disk, upgrade the operating system.)

Personal Computers (with graphics and networking) made their mark from 1995 to 2010. They made the internet available to ordinary people. Graphics made computers easier to use.

Mobile/cloud computers became dominant in 2010. Mobile devices without networks were not enough (the Palm Pilot and the Windows pocket computers never gained much traction). Even networked devices such as the original iPhone and the Nokia N800 saw limited acceptance. It was the combination of networked mobile device and cloud services that became the dominant computing model.

That's my curated version of computing history. It omits a lot, and it fudges some of the dates. But it shows a trend, one that I think is useful to observe.

That trend is: computing models rise and fall, with their typical life being fifteen years.

How is this useful? Looking at the history, we can see that the mobile/cloud computing model has been dominant for slightly less than fifteen years. In other words, its time is just about up.

More interesting is that, according to this trend (and my curated history is too pretty to ignore), something new should come along and replace mobile/cloud as the dominant form of computing.

Let's say that I'm right -- that there is a change coming. What could it be?

It could be any of a number of things. Deep-fake tech allows for the construction of images, convincing images, of any subject. It could be virtual reality, or augmented reality. (The difference is nontrivial: virtual reality makes full images, augmented reality lays images over the scene around us.) It could be watch-based computing. 

My guess is that it will be augmented reality. But that's a guess.

Whatever the new thing is, it will be a different experience from the current mobile/cloud model. Each of the eras of computing had its own experience. Mainframes had an experience of separation and working through operators. Minicomputers had interactive experience, although someone else controlled the computer. Personal computers had interaction and the user owned the computer. Mobile/cloud let people hold computers in their hand and use them on the move.

Also, the next big thing does not eliminate the current big thing. Mobile/cloud did not eliminate web-based systems. Web-based systems did not eliminate desktop applications. Even text-mode interactive applications continue to this day. The next big thing expands the world of computing.

Businesses discover that cloud computing isn't magic

Businesses are now (just now, after more than a decade of cloud computing) discovering that cloud computing is not magic. That it doesn't make their computing cheap. That it doesn't solve their problems.

Some folks have already pointed this out. Looking back, it seems obvious: If all you have done is move your web-based system into cloud-based servers, why would things change? But they miss an important point.

Cloud computing is a form of computing, different from web-based applications and different from desktop applications. (And different from mainframe batch processing of transactions.)

A cloud-based system, to be efficient, must be designed for cloud computing. This means small independent services reading and writing to databases or other services, and everything coordinated through message queues. (If you know what those terms mean, then you understand cloud computing.)

Moving a web-based application into the cloud, unchanged, makes little sense. Or as much sense as moving a desktop-based application (remember those?) such as Word or Excel into the web, unchanged.

So why use cloud computing?

Cloud computing's strengths are redundancy, reliability, and variable power. Redundancy in that a properly designed cloud computing system consists of multiple services, each of which can be hosted on multiple (as in more than one per service) servers. If your system contains a service to perform address validations, that service could be running on one, two or seven different servers. Each instance does the same thing: examine a mailing address and determine the canonical form for that address.

The other components in your system, when they need to validate or normalize an address, issue a request to the validation service. They don't care which server handles the request.

Cloud systems are reliable because of this redundancy. A traditional web-based service would have one address validation server. If that server is unavailable, the service is unavailable for the entire system. Such a failure can lead to the entire system being unavailable.

Cloud systems have variable power. They can create additional instances of any of the services (including our example address validation service) to handle a heavy workload. Traditional web services, with only one server, can see slow response times when that server is overwhelmed with requests. (Sometimes a traditional web system would have more than one server for a service, but the number of servers is fixed and adding a server is a lengthy process. The result is the same: the allocated server or servers are overwhelmed and response time increases.)

Cloud services eliminate this problem by instantiating servers (and their services) as needed. When the address validation server is overwhelmed, the cloud management software detects it and "spins up" more instances. Good cloud management software works in the other direction too, shutting down idle instances.

Those are the advantages of cloud systems. But none of them are free; they all require that you build your system for the cloud. That takes effort.

Technical interviews

Businesses -- large businesses that have HR departments -- have a problem: They find it difficult to hire new staff.

The problem has a few aspects.

First is the processes that businesses have developed for hiring. Businesses have refined their processes over decades. They have automated the application process, they have refined the selection process to filter out the unqualified candidates, and they have documented job descriptions and made pay grades equitable. They have, in short, optimized the hiring process.

But they have optimized it for the pre-COVID market, in which jobs were few and applicants were plentiful. The selection processes have been designed to filter out candidates: to start with a large number of applications and through multiple steps, reduce that list to a manageable three (or five, or ten). The processes have been built on the assumption that many candidates wanted to work at the company, and were willing to undergo phone screens, interviews, and take-home tests.

The current market is a poor fit for these practices. Candidates are less willing to undergo day-long interviews. They demand payment for take-home tests (some of which can take hours). Candidates are especially reluctant to undergo the process multiple times, for multiple positions. The result is that companies cannot hire new staff. ("No one wants to work!" cry the companies, but a better description might be "Very few people are willing to jump through all of our hoops!")

One might think that companies could simply change their hiring processes. There is an obstacle to this: Human Resources.

Most people think that the purposes of Human Resources are to hire people, occasionally fire them, and administer wages and benefits. They miss an important purpose for HR: to keep the company out of court.

Human Resources is there to prevent lawsuits. Lawsuits from employees who claim harassment, candidates who were not hired, employees whose employment was terminated, employees who are unhappy with their annual performance review, ... you get the idea.

HR meets this objective by enforcing consistency. They administer consistent annual evaluations. They document employee performance prior to termination of employment. They define and execute consistent hiring practices.

Note that last item: consistent hiring practices. One of the ways that HR deflects lawsuits is by ensuring that hiring practices are consistent for all candidates (or all candidates in broad classes). Consistency is required not only across employees but also over time. A consistent approach (to hiring, performance review, or termination of employment) is a strong defense against claims of discrimination.

The suggestion that HR change its hiring practices goes against the "consistency" mandate. And HR has a good case for keeping its practices consistent.

Companies must balance the need for staff against the risk of lawsuits (from a change in practices). It is not an easy call, and one that should not be made lightly. And something to keep in mind: The job market may shift back to the previous state of "many candidates for few openings". Should a company adjust its practices for a shift in the market that may be temporary? Should it shift again when the market changes back?

I don't have simple, definite answers. Each company must find its own.

Success with C++

Having recently written on the possible decline of C++, it is perhaps only fair that I share a success story about C++. The C++ programming language is still alive, and still useful. I should know, because a recent project used C++, and successfully!

The project was to maintain and enhance an existing C++ program. The program was written by other programmers before I arrived, over a period of years. Most of the original developers were no longer on the project. (In other words, a legacy system.)

The program itself is small by today's standards, with less than 300,000 lines of source code. It also has an unusual design (by today's standards): The program calculates economic forecasts, using a set of input data. It has no interaction with the user; the calculations are made completely with nothing more than the input data and program logic.

We (the development team) have successfully maintained and enhanced this program by following some rules, and placing some constraints upon ourselves. The goal was to make the code easy to read, easy to debug, and easy to modify. We made some design decisions for performance, but only after our initial design was shown to be slow. These constraints, I think, were key to our success.

We use a subset of C++. The language is large and offers many capabilities; we pick those that are necessary. We use classes. We rarely use inheritance. Instead, we build classes from composition. Thus, we had no problems with slicing of objects. (Slicing is an effect that can occur in C++, when casting a derived class to a base class. It generally does not occur in other OOP languages.) There are a very small number of classes that use inheritance, and in those cases we often want slicing.

We use STL but not BOOST. The STL (the Standard Template Library) is enough for our needs, and we use only what we need: strings, vectors, maps, and an occasional algorithm.

We followed the Java convention for files, classes, class names, and function names. That is, each class is stored in its own file. (In C++, we have two files, for the header file and the source file.) The name of the file is the name of the class (with a ".h" or ".cpp" extension). The class name uses camel-case, with a capital letter at the beginning of each word, for names such as "Year" or "HitAdjustment". Function names use snake-case with all lower-case letters and underscores between words. This naming convention simplified a lot of our code. When creating objects, we could create an object of type Year and name it "year". (The older code using no naming conventions, and many classes had lower-case names, which meant that when creating an object of type "ymd" (for example) we had to pick a name like "my_ymd" and keep track mentally of what was a class name and what was a variable name.)

We do not use namespaces. That is, we do not "use std" or any other namespace. This forces us to specify the namespace for every class. While tedious, it provides the benefit that one can easily see the class for function names. There is no need to search through the code, or guess about a function.

We use operator overloading only for a few classes, and only when the operators are obvious. Most of our code uses function calls. This also reduces guesswork by developers.

We have no friend classes and no friend functions. (We could use them, but we don't need them.)

Our attitude towards memory management is casual. Current operating systems provide a 2 gigabyte space for our programs, and that is enough for our needs. (It has been so far.) We avoid pointers and dynamic allocation of memory. STL allocates memory for its objects, and we assume that it will manage that memory properly.

We do not use lambdas or closures. (We could use them, but we don't need them.)

We use spacing in our code to separate sections of code. We also use spacing to denote statements that are split across multiple lines. (A blank in front and a blank after.)

We use simple expressions. This increases the number of source lines, which eases debugging (we can see intermediate results). We let the C++ compiler optimize expressions for "release" builds.

----

By using a subset of C++, and carefully picking which features make up that subset, we have successfully developed, deployed, and maintained a modest-sized C++ application.

These constraints are not traditionally considered part of the C++ language. We enforce them for our code. It provides us with a consistent style of code, and one that we find readable. New team members find that they can read and understand the code, which was one of our goals. We can quickly make changes, test them, and deploy them -- another goal.

These choices work for us, but we don't claim that they will work for other teams. You may have an application that has a different design, a different user interface, or a different set of computations, and it may require a different set of C++ code.

I don't say that you should use these constraints on your project. But I do say this: you may want to consider some constraints for your code style. We found that these constraints let us move forward, slowly at first and then rapidly.

The end of C++

The language wars are back!

Well, one war -- between C++ and Rust.

Perhaps "war" is too strong a word. A better description is "a discussion".

Programmers do like to participate in language wars. Or they used to, back in the days prior to open source and the internet. Back then, a programmer worked with the language that was chosen by his employer, or a language for which he (and programmers were overwhelmingly men) had spent money to acquire the compiler or interpreter. One's programming language was fixed, either by company mandate or by finances. That caused false pride in their programming language.

Open source and the internet made it possible for programmers to easily switch. They could try one and change if they found it better than their current language. With the ability to change, programmer's didn't need false pride, and didn't have to argue the merits of a language that they were most likely unhappy with. The language wars faded.

Until now. There were two events this past week, both concerning programming languages.

The first involved the Linux kernel. Linus Torvalds, the chief maintainer for the Linux kernel, announced that he would allow code written in Rust (an up-and-coming programming language) to be part of the kernel. (The kernel, up to now, has been written exclusively in C.) This announcement angered the C++ advocates, who would have preferred that language. Various arguments bounced across the internet, extolling the virtues of each. (Mostly "Rust is a safe language, designed to prevent many mistakes that can happen in C and in C++." and "C++ is a time-tested language with a mature toolset and a large base of experienced developers.")

It wasn't a war, or even a battle, but a discussion with lots of emotion.

The second event was an announcement from Microsoft's CTO for Azure. He stated that organizations and individuals should stop choosing C++ for new projects, and instead pick other languages. (I don't think he listed the languages, but I suspect he would prefer languages supported by the Azure platform.)

That announcement received much less interest. But still, it counts as a volley in the language disputes.

(I suspect that the Microsoft CTO is right, but for a different reason: the size of applications. C++ was designed for large systems, and today's cloud-based services are much smaller. They don't need C++; they need a language larger than C, smaller than C++, and safer than both.)

I find the timing of these two announcements interesting. It may be that we are seeing the beginning of the end for C++.

It may be that historians, in some distant future, draw a line and say "Here, here in 2022, is where C++ began its decline. This is the time that the IT world started to move away from C++."

I don't expect C++ to disappear. Some programming languages have "disappeared" in that they are used for nothing outside of a few museum exhibits and systems run by die-hard fans. Programming languages such as Flowmatic, Neliac, BASIC, and Modula-2 are all but unused in the modern world.

Yet other old languages continue to be used: Cobol, Fortran, and even RPG are running systems today. I expect C++ to join their ranks. They will remain, they will continue to do useful work, and they will be present in popularity surveys. But they won't be at the top.

Where has the FUD gone?

A long time ago, the IT industry was subjected to FUD (Fear, Uncertainty, Doubt) advertising campaigns.

FUD was a marketing strategy used by IBM. When competitors announce a new product (or worse, a breakthrough product), IBM would announce a similar product, but only in broad terms. The idea was to encourage people to wait for IBM's product, thereby reducing sales of the competing product. (It also created hype for the IBM product.)

To be effective, a FUD announcement had to describe a future product. It created doubt and uncertainty, and fear of making a bad choice of technology.

I haven't seen a FUD announcement for a long time.

They were common when IBM was the dominant manufacturer for computing equipment. The FUD campaign may have ended shortly after the introduction of the PS/2 (itself a product with a FUD announcement) line of computers. The market rejected the PS/2's Micro Channel Architecture, and accepted Compaq's ISA (the old PC standard architecture) with its 80368 processors. (Although the market did adopt IBM's VGA display and 1.44 MB hard "floppy" disk as standards.)

Compaq didn't use FUD announcements to take the lead from IBM. It delivered products, and its announcements for those products were specific. The message was "our products have this technology and you can buy them today".

There is one company today which has something similar to FUD announcements. But they are different from the old-style FUD announcements of yesteryear.

That company is Apple.

Apple is the one company that announces future products. It does it in a number of ways, from its annual marketing events to its reliable product schedule. (Everyone knows that Apple releases new iPhones in September, for example.)

Apple's FUD campaign seems to be accidental. I don't think that Apple is playing the same game that IBM played in the 1980s. IBM made FUD announcements to deter people from buying products from other companies. Apple may be doing the same thing, but instead of affecting other companies, I think it is Apple itself that suffers from these announcements.

Apple announcing a new processor for its MacBook line doesn't deter people from buying Windows laptops. They need laptops, they have already chosen Windows (for whatever reason) and they are going to buy them. Very few people change their purchasing decision from Windows to a yet-to-be-defined MacBook.

But a lot of Apple users defer their purchases. Many Apple users, in the middle of planning an upgrade, put off their purchase until the new MacBook was released.

Trade publications advise people to defer the purchase of Mac Minis, based on Apple's announcements and regular product schedule.

This behavior is the same as IBM's FUD from thirty years ago -- but with the difference that the (unintentional) target is the company itself.

It may be that Apple is aware of customers deferring their purchases. Perhaps Apple wants that behavior. After all, if Apple withheld new product information until the release of the product, those who recently purchased the older version may feel betrayed by Apple. It may be that Apple is forgoing immediate revenue in exchange for customer goodwill.

I'm happy to live in a world without FUD announcements. The IT world with FUD has challenges for planning, and a constant fear of missing out on important technology. The current world is a much more relaxed place. (That may sound odd to technology managers, but believe me, today's world is much better than the older one.)

E-mail Addresses Considered Harmful

PCWorld lost (temporarily) their YouTube account because their e-mail address changed.

YouTube, like many web services, uses e-mail addresses for customer IDs. This, I think, is a poor practice.

Many web services and many cloud services create dependencies on an email address. Your account ID is your email address. (This is a cheap way to ensure unique IDs.) When updating my e-mail address on these sites, I am changing my ID.

IDs should be unique, short, and permanent. E-mail addresses are unique, and they are usually short, but they are not permanent. E-mail addresses can change. Specifically, e-mail addresses can change outside of the control of the organization that uses them as IDs. I changed my main e-mail address recently, and had to go through all of my accounts (I keep a list) and update each of them.

For most sites, I was able to change my e-mail address. Some sites let me change my contact e-mail address but did not allow me to change my ID. Those sites send e-mails to my new address, but I must use my old e-mail address to log in. Other sites let me change my e-mail address as ID, but kept sending notifications to my old e-mail address. (Their web site stores the e-mail addresses for notifications as a copy of the login ID, and those e-mail addresses are not updated when the ID is changed.)

Clearly, different web sites have different ideas about the separation of ID and e-mail.

Companies running web services, or cloud services, should carefully select their IDs for customers. How do they use those IDs? Are they stored in databases? Are they keys in databases? If a customer changes their e-mail address, what happens to the records with the old e-mail address? How does a new e-mail address affect queries? Do the two e-mail addresses appear as two different customers?

This is why database keys (and user IDs) should be unique and permanent.

Banks and insurance companies understand this. I am a customer to a few insurance companies and several banks. All of them -- without exception -- use their own IDs for my account. Not email addresses.

The underlying concept here is ownership. When I open an account with a bank and they ask me to provide an ID (not an e-mail), they are really asking me to pick an ID from a (very) large set of unused IDs that conform to their rules (so many letters and digits). I pick the ID, but they own it. They can change it if they want. (I've never seen that happen, but it could.) And if they change it, nothing else in my electronic life changes.

An e-mail address, in contrast, is owned by the e-mail provider (GMail, Yahoo, Microsoft, etc.). I don't own it, I merely "rent" it. Anyone I give it to, either a friend, colleague, or web service, is only borrowing it. It can be withdrawn from circulation at any time, either by me or the e-mail service.

Building a service on data that you don't own is risky. I understand the appeal of e-mail addresses as IDs. (It is easy, everyone else does it, it doesn't require our own code to create new IDs for customers, and anyway customers don't want another ID for our service and that is a disincentive for them to use our new service so use the e-mail addresses because the folks in marketing want it that way.)

Yet I must balance those appealing factors with the risks. For individuals, the e-mail address may be an acceptable ID. For corporate accounts, e-mail addresses as ID pose risks to the customer. (Just as PCWorld.)

In essence, using e-mail addresses as IDs is simple for the service, but imposes risks on customers. That may not be the best of business practices.