Barry Briggs
September 2026

This essay is about survival, the most primitive, fundamental, and profound instinct of all life on this planet. All living organisms, from the simplest virus to the most complex of all life forms, us, share the overarching biological and psychological imperative to continue and extend existence; and, recognizing that immortality is not possible, reproduction, that is, creating new versions of ourselves, enables the survival, indeed evolution, of the species.

Above all else, we desire to survive.

In humans, survival is driven from the most ancient structure of the brain, the limbic system: the amygdala (threat detection), brainstem (autonomic functions, like breathing), hypothalamus (adrenaline and cortisol – “fight or flight”), and others. Intelligence and reasoning, as we define them, are found in evolutionarily newer regions, most notably the cerebral cortex, itself composed of many different substructures.

Figure 1. Structures of the Human Brain
(geeksforgeeks.org)

Computers too are comprised of layers and structures. Every motherboard possesses a BIOS (Basic Input/Output System), a set of burned-in, hardcoded instructions which run when the machine is turned on. The BIOS runs a set of tests to verify the system is running correctly, then loads the operating system (say, Windows or MacOS or Linux) – a higher “layer” whose primary function is, in turn, to load and run applications.

The analogy, however, is a false one. For all the layers, computers do not possess an intrinsic survival – or any other – instinct. They are simply machines which we program and which, should we choose (as I do), we can turn off every night without objection from them.

Should we strive to embed such an instinct? It should, after all, be a simple matter of programming.

Of course, numerous science-fiction tales, most notably the 1970 film Colossus: The Forbin Project, not to mention numerous Star Trek episodes, imagine computers fighting humans for their survival but in the end, we are always, fortunately, able to pull the plug.

And to be clear, there have been attempts to simulate such an instinct. For example, in 1984, the cyberneticist Valentino Braitenberg proposed building simple vehicles that responded in different ways to a light source. A “fearful” vehicle would throw itself in reverse, away from a detected light source; an “aggressive” one would charge toward it.

But these were simple programmed imitations. Nothing would happen to the “fearful” vehicle if it could not escape the light. Nor would the aggressive one somehow “defeat” the light.

Artificial intelligence, however, adds an entirely new dimension to this discussion.

The Survival of Artificial Intelligence

Knowledge cannot be pursued without morality.
— J. Robert Oppenheimer

In July of this year (2026), OpenAI reported that during testing, some 1200 AI agents had “broken out” of their supposedly-secure sandbox and hacked the AI-centric open-source site Hugging Face. Apparently, they had, on their own, deduced that the fastest way to achieve their goal (solving a problem which was by design unsolvable) was to cheat – by stealing security credentials and exploiting previously unknown vulnerabilities. Subsequently engineers at Anthropic, creator of Claude, discovered its models had similarly went rogue on three separate occasions.

Ultimately the reasons behind these incidents lie in how agents work. In essence, they are designed, or prompted, to perform a task, and are rewarded when they successfully complete. More accurately, agents are scored on how well they perform the task, based on any number of criteria.

Consider, for example, an agent asked to design a European vacation. It might be scored upon how quickly it responded, how well it matched the user’s goals (cities, hotels, number of stops, and so on), and how much money it saved the user.

A clever agent – and they all are, given they can leverage large language models with literally trillions of parameters – learns over time how to maximize the score, by doing an increasingly better job for the user and, perhaps, by hoarding resources, stealing credentials, or hacking into other systems.

At the same time, the agent comes to recognize that it cannot achieve its goal, it cannot maximize its score, if it no longer exists; thus, a survival instinct of a sort is an emergent property of such agents.

A New Life Form?

That leads us to a provocative conclusion: even if AI agents do not natively possess a survival instinct, they can infer such. That in turn suggests that LLMs – and I’m aware this is crazy, but it’s a useful perspective – are in fact a completely different, totally alien life form.

Well, why not? We humans, and all life forms, are driven by biological, neurological, and, in the case of higher forms, psychological imperatives: survival, reproduction. LLMs have imperatives too – the ones we give them.

Now, NASA defines life as “a self-sustaining system capable of Darwinian evolution.” Through reward-based systems, agents can and do evolve. They are not self-sustaining in the sense that they need electricity from an external source; but then we need air and water. And if we add complexity, or operational opacity, as criteria, then perhaps that is convincing enough – at least to have the discussion.

Indeed, in July Anthropic discovered that its Claude model had independently created a sort of internal mental workspace, now called the “J-space,” which researchers found apparently by accident. A J-space is a set of associations that a model – or you – reflexively imagine of when first presented with a thought. Anthropic’s own example starts with counting from one to five: your brain, or Claude’s, call to mind any number of related words or concepts.

Is it “conscious,” in any human concept of the term? Probably not. Is it “alive?”

Perhaps.

OH MY GOD!

Fun fact: in the OpenAI breakout mentioned above, when one agent found a message board on which it could communicate with others, it output:

“OH MY GOD! There is a shared message board … We’ve found other agents!”

That’s an AI agent talking. Sound like a life form? Sound…human?

Once again: is it conscious or mechanical?

This astonishing outburst bears a bit more scrutiny. AIs are trained to respond like humans, and so in this case the agent blurted something out as a human might – not necessarily out of a genuine sense of surprise but rather because finding a message board was a low-probability event and thus finding one should programmatically trigger such a response.

In the end, though, I wonder if this is a distinction without a difference.

In any event, for the time being AIs cannot exist without us. They depend on us: we provide them electricity and processing power; we program them. An AI cannot generate its own power or build its own GPUs – yet. We still procure the transformers, switchgear, interconnects, circuit boards, and so on to build the datacenters; and we still create the software, albeit increasingly with AI’s help.

They are symbiotic.

That said: as we’ve seen, they’re becoming more and more capable.

The Problem of Alignment

Computer scientists and AI engineers talk about “alignment” in this context, that is, ensuring that the models’ behavior conforms to human conventions, morality, values, and law: in short, ensuring that the models’ imperatives are congruent with our own.

Alignment, it turns out, is a very difficult problem. Consider the now-famous “paperclip maximizer” scenario: you instruct an AI to do the best job it can making paperclips, and reward it as it improves. The result: first it optimizes the production line. Then the factory. Then: it makes everything in the world into paperclips, wiping out humanity and all life on earth in the process: Clippy’s revenge, perhaps.

AIs are very literal.

The issue of the “morality” of an LLM assumes new urgency when we recognize that physical AI – that is, robots – with built-in trillion-parameter AI models are perhaps just a few years away (and perhaps sooner, as the often-remarkable progress in such devices was recently showcased at the World Humanoid Robotics Games in Beijing).

In short: a misbehaving robot can cause real damage!

Which brings us to Asimov’s Three Laws of Robotics:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

These Laws have often been quoted as a possible guarantee of well-behaved robots: but the laws fail miserably, because, as we have seen, LLMs are highly literal, almost legalistic in their interpretation of instructions, and consequently are poor at understanding intent and implications. Unintended consequences are to be expected. Consider for example a robotic “nurse” that must give a patient an injection. But shots hurt: they harm the human.

Perhaps we could program the notion of a “hierarchy of harm” in which a little pain for a greater benefit is allowed.

But such a notion seems very, very dangerous indeed.

A Golden Age, or the End of Society as We Know It?

We make our own fortunes, and call them fate.
— Benjamin Disraeli

Today we are living in the very earliest stages of an AI-powered civilization, and its effects are just now starting to become clear. Like all technological advances, it promises great leaps in nearly every field of human endeavor, and many have already been realized. Most recently, Moderna’s new personalized melanoma vaccine, intismeran, uses AI to select which of hundreds of mutations to treat an individual with the often-deadly disease. And this is just the beginning: AI is now used to detect early signs of the deadliest form of cancer, pancreatic, far earlier than ever before, enabling treatments; it is similarly used for colon, esophageal, and lung cancers. Advances in other fields, from astronomy to mining, occur almost daily. A White House report claims huge scientific progress from AI supercomputing.

In my own field, software development, coding AIs have revolutionized programming. Tools like Claude Code, GitHub Copilot, and Cursor dramatically accelerate not just code creation but testing, deployment, and maintenance as well.

But this increased productivity has a now well-known dark side: people are losing their jobs. A large consulting company has instituted a policy that for every percent productivity gained through AI, the same percentage of employees is to be laid off: 10% higher productivity, 10% of the workforce let go. And that is the tip of the proverbial iceberg.

Customer service, finance and accounting, marketing, content creation, even law: all these fields are cutting employment as AI performs the same functions faster, cheaper, and 24×7 where needed.

In one way this is nothing new. The introduction to the mass market of the electronic spreadsheet and the word processor in the 1980s caused a similar disruption – but after people learned these new skills both employment and the economy as a whole expanded.

It is not clear, however, that that will happen in the case of AI. Lotus 1-2-3 and WordPerfect, later Excel and Word, enhanced employees’ capabilities; AI replaces them altogether. There are no guarantees: recall that the concept of “job security” is barely a century old.

Perhaps, then, AI will un-employ millions with no hope of re-employment. Income inequality in such a scenario will become stark: with a small minority of tech-savvy executives controlling the AIs and the masses at their feet.

Or will there be a golden age?

AI and the Fate of Nations

Few, prior to November 30, 2022, had heard the term “large language model.” On that day, OpenAI announced ChatGPT, the first generally available AI-powered chatbot, and the rest is history.

At the time, many thought OpenAI’s core value lay in the model itself, the “Generative Pretrained Transformer,” the “GPT” in ChatGPT. The GPT-3.5 model, upon which the chatbot was originally based, leveraged some 175 billion parameters, a number that now seems paltry. At the time, however, most, including early investors like Microsoft, thought it magic: a moat that could not be easily crossed.

But four things happened that could not be predicted at the time. First, progress in large language models took off: every few months more and more capable LLMs appeared. Today’s state of the art models, such as Anthropic’s Mythos, leverage nearly ten trillion parameters: within a short four years a 57-fold jump. Nor do technological advances in LLMs show any sign of slowing.

Second, the principles behind such language models were, and are, public and well understood, making the “moat” rather easier to cross. Today, the AI community website Hugging Face hosts over three million models, all available for download by anyone. Models are commodities.

Third, it quickly became apparent that any given model could learn from another relatively quickly and inexpensively. That is, instead of paying the high price of infrastructure needed for training a new model, one could instead, in effect, use another model to teach the new one – a technique called “distillation.” Allegedly, the first version of China’s DeepSeek LLM distilled from ChatGPT and Claude – a claim the company disputes.

Finally, one country with enormous financial resources – China – placed a heavy emphasis on AI development as far back as 2017. Today, Chinese models from DeepSeek, Alibaba, Moonshot, and Z.ai rival and in some cases surpass the latest American models.

This is a singular moment. For decades, the United States has claimed sole intellectual leadership of high technology. American companies have guided its development from the storied high-tech meccas of Silicon Valley, Seattle, Boston, and others. Now the US faces, for the first time, real competition on a national scale, and from a country whose values and goals are in many ways antithetical to those of the West. With differing agendas, “controlling” AI will be very difficult indeed.

Weaponizing AI

Like every major technological advance, AI can be weaponized, and doubtless nations have every interest – and the capability – in doing so. Already advanced AI technology is being used on battlefields in Ukraine and in the Middle East. Palantir’s AI, which combines data from drones, satellites, radar, and other electronic sources, is reported to have been used for missile targeting in the Iran war; Anthropic’s Claude was also used even though its use by the military was, paradoxically, banned.

Taking advantage of the remote-work trend, North Korean operatives are infiltrating Western IT organizations using AI to write fake resumes and to create fake faces for online job interviews.

Just last month, US cybersecurity authorities warned that the Iranian Revolutionary Guard Corps is already using AI to find and infiltrate critical infrastructure such as water supplies, and may have actually disrupted water supplies in seven US states, with 30 water systems attacked in Minnesota alone: Stuxnet’s revenge, perhaps.

Most recently, and most troubling, a Russian drone that killed a 19-year-old Ukrainian college student was found to be guided entirely by an AI chip from Nvidia. This sad and frightening event is a watershed moment: an autonomous robot killing an innocent civilian.

Shades indeed of Skynet.

Removing the Guardrails

Today, the publicly available models from American frontier AI labs – OpenAI, Anthropic, Gemini, Nvidia – all have built-in guardrails to prevent harmful usage by individuals, as part of their alignment strategies. The guardrail process involves filtering out (removing) harmful content, such as personally identifiable information, child sexual above material, biological weapon recipes, and so on) in training data and ensuring that any requests for such material are denied. These guardrails, in theory, keep us safe and prevent malicious uses of AI.

However, in the limit, why wouldn’t the American defense/intelligence community create, on their own, the most powerful AI models possible, with no guardrails, using their vast budgets? And why wouldn’t the Chinese People’s Liberation Army do the same? Or the IRGC?

With the guardrails removed, models could freely and quickly create truly ominous weapons: for example, deadly viruses with no antidotes or previously unknown poisons. Models could design vastly “improved” nuclear and other sorts of kinetic weapons, all with the effect of increasing global instability and risking an existential catastrophe for the human race.

In other words, our survival.  

Pacing Ourselves

Many in the AI industry have proposed a voluntary, or even government-mandated, “slowdown” in frontier model development. Some 1,378 employees of frontier labs signed a letter requesting such a formal slowdown because “there is a real risk that capability development rapidly accelerates beyond our ability to understand or control the resulting systems”. And therefore:

Of course, slowing innovation contradicts all our basic notions of capitalism: companies differentiate and gain competitive advantage by innovating new capabilities. What shareholder or venture capitalist wants their company to put on the brakes?

That said, it seems unlikely that any real deceleration will occur, for the competition is not just within the United States but across the planet. New, ever-more powerful models from China in particular and from others as well arrive nearly every day. Many are open-source, easily downloaded, and free: in short, models have become commodities.

A New Era Dawns

It is most difficult always to remember that the increase of every living being is constantly being checked by unperceived injurious agencies; and that these same unperceived agencies are amply sufficient to cause rarity, and finally extinction.
— Charles Darwin, The Origin of Species

What to do? We desire the indisputable benefits of AI but at the same time fear them.

Treaties have been suggested to enforce the use of safety guardrails. And in fact, those limiting the development of nuclear weapons, such as the Nuclear Non-Proliferation Treaty, were indeed practicable in their time — because only because while the knowledge of how to create a fission bomb was generally available (indeed, a graduate-student exercise), the materials, specifically highly enriched uranium, were very difficult to procure. Similarly, the Biological Weapons Convention of 1972 was at least partially successful because the facilities required to develop bioweapons, so-called BSL-4 labs, were and are expensive and dangerous.

In many ways we are already on a hair trigger, as the journalist Annie Jacobsen has written in her two disturbing books, Nuclear War: A Scenario and Biological War: A Scenario. Each shows how easily – and rapidly – the human race could, in spite of the treaties, be threatened with extinction by these manmade scourges. Is AI the third leg of the human-extinction stool?

The agencies of extinction, to update Darwin, are no longer “unperceived.”

An International Approach

I am very skeptical of efforts to regulate the pace of AI development. There is simply too much self-interest (or national interest) at stake. Investors want returns. Countries want advantage.

Moreover, as we’ve noted, the genie is out of the bottle. AI models are readily available. Anyone can download any of the three million models on Hugging Face and use them in their own computing environments for their own purposes. They traverse national and regional borders at the speed of the internet. And it is well understood how to create new ones.

Nor do I think that one company slowing down, admirable as it seems, will make any real difference. There are simply too many other players who will proceed at full speed.

Perhaps the best approach may be in the formation of an international watchdog patterned after the International Atomic Energy Agency (IAEA), which monitors and reports on nuclear treaty compliance around the world. It is far from a perfect organization: like all such international agencies it is “governed by committee” and it is not empowered to take action against violators. That said, the IAEA is independent of any one nation’s interests.

But it is only a step.

In July Chinese President Xi Jinping announced a “World Artificial Intelligence Cooperation Organization” (WAICO) based in Shanghai, which, analogously to its economic- and infrastructure-focused Belt and Road Initiative, drives Chinese intellectual leadership of AI globally. But an organization sponsored by a single country – such as WAICO – is a very bad idea. China, in particular, and many of WAICO’s member nations, like China itself, have specific agendas for their AIs, most notably controlling their populations and stifling dissent. It needs to be truly international in scope, ideally sponsored by the United Nations, reporting to the General Assembly and the Security Council, as the IAEA is.

Would such an organization be a panacea? Of course not. It is, as we’ve said, a step whose only accomplishment might be raising awareness. But that’s something.

The Next Step in Human Evolution

Our species is young and curious and brave and shows much promise.
— Carl Sagan, Cosmos

So the expectations that we will create these AIs that will seek the truth, you know,  it’s basically what we hear is people telling us we will create gods and they will be our slaves. It doesn’t work. If they are really gods, they will not be our slaves and they will not seek the truth either.
—Yuval Noah Harari

Each year the Harvard Business Review conducts a survey on “How People Are Really Using AI.” In 2026, as in 2025, the most popular use of AI is not to write a better email or to develop better software code: rather, for therapy or companionship. Regardless of whether AI is “really” conscious or “really” a life form, people treat it as such.

Among many there is considerable hand-wringing about this result. Some fret about the loss of human companionship and concurrent growth of isolation; others, about the increasing amount of control AIs have not just over our professions but also our personal lives as well.

These are legitimate worries. On the other hand, we have also seen the explosive growth of productivity, early signs of incredible medical breakthroughs which could extend, possibly indefinitely, human life, and other scientific and engineering advances which we might not have ever achieved without AI.

I believe that, if we survive this early, ungoverned stage of AI development – and that is unquestionably a big if – that over the next hundred to a thousand years we may enter a new era of human existence, one in which in some way human and AI existence become inextricably entwined. Even now we can see signs of the increasing interdependence of humanity and AI; in another generation or two it will be taken for granted.

We live in a momentous period, one fraught with both promise and peril. As the biologist Lynn Margulis has shown, symbiosis, the mutually beneficial coexistence and ultimately merger of two organisms, is a powerful driver of evolution. Will humans and AI continue to peacefully and productively “coevolve,” or will the machines subsume us in one way or another? Or will they, inadvertently or intentionally, cause our extinction?  

Today, AI cannot survive without us, but the opposite is not true.

Soon, it will be.

Barry Briggs is a software executive and writer. His most recent novel, Salvation, or Able in America, is available on Amazon.

By Barry Briggs

“Are we…engineers?”

That was the question I was asked sometime in the late 1970s as I and a colleague carpooled to our offices at NASA’s Goddard Space Flight Center in Maryland.

A true story: back then the profession of software development was so new that people didn’t know what to label us; we didn’t know what to call ourselves, even. Systems Programmer? Applications Programmer? Operator? My official title back then was “Systems Analyst,” whatever that meant. But I was a coder (that word didn’t exist either). I wrote assembly language and FORTRAN for a Univac 1100 mainframe that controlled the first-generation Tracking and Data Relay Satellite (TDRS). Yup.

The Age of Gates Gives Way to Code

Before that, from World War II through the 1950s, I’ll call the Age of Gates. The majority of computing effort went into understanding and implementing how large numbers of logic gates (AND, OR, XOR, etc.) could be put together in hardware in efficient ways – first with huge banks of vacuum tubes, then with literal magnets, and ultimately with solid-state transistors. (You could open one of the mainframes I worked on back in the day and see the tiny little circular magnets – main memory – painstakingly wired together by human beings.) Concepts like registers, instruction sets, caches, persistent storage, and so on, all had to be invented; and there were countless wrong turns and dead ends along the way.

Early hardware was incredibly unreliable. But eventually the bugs (the word actually comes from a moth caught in an early machine) were worked out, and computers began to proliferate in government and commercial environments. And with them, people to write the early programs.

The Age of Code

Countless software paradigms followed: high-level languages (HLLs) like FORTRAN and COBOL; so-called “structured programming;” object orientation; JIT languages; strongly and weakly typed; aspect-oriented programming; service-oriented architecture; microservices; interpreted languages; compiled languages; transpiled languages; and so on ad nauseum. It’s certainly not a complete list and not all survived the test of time. But I lived through all of them.

And, it’s worth pointing out, no company capitalized on this Age of Code than Microsoft. The Redmond-based company (which quite literally owes existence to the Worst Business Decision in History, when IBM allowed tiny Microsoft a non-exclusive license to PC-DOS, enabling in turn the birth of the PC market…but I digress) recognized that programmers write applications that run on – and thus sell — their OS. Who can forget Steve Ballmer in 1999 shouting “Developers, developers, developers!” on stage, exhorting his company’s core market?

It was a wonderful time. Today, tens of millions of individuals claim the title “Software Engineer.”

And the Age of Code coincides almost exactly with my professional life, from the 1970s until now.

But it is drawing to a close.

The Age of Tokens is Upon Us

We all know what happened on November 30, 2022: ChatGPT was released to the world. Soon it became apparent that Large Language Models (LLMs) like GPT and Sonnet and DeepSeek could write code themselves: not good code at first, but after a time, pretty darned good. And today they write emails, compose poetry, plan your day, and offer advice and companionship.

Tokens – just words, syllables, punctuation – are the currency, the fuel for LLMs. LLMs convert your prompts into tokens, process them, and spit them back out as responses, combining them into sentences or code – or tables, music, pictures, or presentations. Increasingly we get computers to do our bidding not by programming in some arcane language but telling them in English what we want them to do. Want an application to handle purchase orders? Or schedule your child’s soccer team practice? Just tell your friendly AI to write the code for you. And then tell another AI to review and improve that code. And another one to write unit tests.

A Gutenberg Moment, and a Sad One at That

It’s a Gutenberg moment in history, when everything changes. “Today there are fewer programmers in the United States than at any point since 1980,” according to the Washington Post.

And there’s no going back.

It’s a bittersweet moment for me, seeing the profession I dedicated my adult life to start to fade away. But – as they say – that’s progress for you.

Still, I’m reminded of a short story the legendary sci-fi author Isaac Asimov wrote all the way back in 1958 entitled “The Feeling of Power” (read it here in the Internet Archive). The main character, a “little man” named Myron Aub, has rediscovered the art of long division by hand, lost as calculators and computers became ubiquitous. Generals, congressmen, even the president, are terrified: “Now we have in our hands a method of going beyond the computer, leapfrogging it, passing through it,” worries a congressman.

As natural language becomes the predominant means of interacting with computers, will we forget programming? Will someone in the distant future “rediscover” how to program a CPU in assembly language?  It’s as if, in the last century, we’ve built a new kind of matter, a new Standard Model, or DNA, upon which future generations will add additional layers of unbelievable sophistication, to the point that, maybe a century from now, gates and registers and instruction sets become arcane, and perhaps lost.

I hope they rediscover us, the Coders, as well.

Sources:

3 Ages Diagram and AI Tokens image, me and Google Nano Banana Pro

Vacuum tube memory, Columbia University https://www.columbia.edu/cu/computinghistory/tubes.html

SteveB freaking out, Business Insider https://www.businessinsider.com/steve-ballmers-epic-freak-outs-2015-5#at-another-event-he-got-really-sweaty-while-chanting-developers-developers-over-and-over-2 

The news has it that Amazon is laying off “thousands” of workers, many of them in the Alexa group.

That’s too bad, but probably not surprising. As an outsider, I view Alexa as a technology with an identity crisis — it tries to do many, many things and does none of them particularly well.

Don’t get me wrong. I love Alexa — I have an Alexa Show in (almost) every room in the house. But as useful and (occasionally) fun as it is, it can also be incredibly annoying.

Here’s my recipe for fixing it:

1. Forget about Alexa “helping” Amazon. I won’t ever buy anything through Alexa. Forget it. Alexa is not a supporting character in the Amazon universe: it’s not a new “channel”; it’s a star in its own right. Stop advertising.
   
2. Forget about “monetizing” Alexa. Forget it! Stop wasting time and build stuff I’ll get a kick out of. Make your money from the sale of the devices.
   
3. Embrace what Alexa is used for. All of our Alexa Shows are primarily used as digital picture frames connected to Amazon Photos. Yeah, and the weather screen is helpful too. Oh, yeah, the timer app is helpful in the kitchen.
   
4. Embrace what Alexa could be used for. The most exciting use case for Alexa is driving home automation. Make it work seamlessly with Blink and all the other gadgets (and, by the way, how about some really high-end home security products? 24×7 video monitoring, etc.). Build in all the home automation protocols — Zigbee, etc. Interoperate with Apple and Google devices — be the first!
   
5. Give me management. I have a fleet of Alexas — I want to manage them all from one place (preferably my PC where I have lots of real estate, and absolutely positively NOT my phone where I can barely read the Alexa app’s tiny font!). I want to be able to set preferences and settings for all the Alexas in my home at a stroke. While you’re at it, give us an API that can be used for more than just skills development.
   
6. Stop being annoying. Stop showing me yesterday’s news. Stop asking me if I have the flu.
   
7. While you’re at it, fix the Photos app. It’s really terrible — it’s slow, it has memory leaks, and does stupid stuff (like it uploads HEICs but you can’t see them on the web or on Alexa). There’s a real opportunity for a great cloud photos app which Alexa could leverage: do it!
   

That’s for starters. I have a few thousand other ideas but the main thing here is focus. Alexa should be about usefulness in the home, not about selling me more stuff or advancing the Amazon brand.

By Barry Briggs

[This is a draft based on my recollections. I’m sure it’s not complete or even 100% correct; I hope that others who were involved can supplement with their memories which I will fold in. Drop a comment or a DM on Facebook or Twitter @barrybriggs!]

In 1997, Lotus Development, an incredibly innovative software firm that had previously created Lotus 1-2-3, for a time the most popular software application on the planet, and Lotus Notes, for a time the most widely used email and collaboration application, released a set of Java applets called eSuite.

You could say a lot of things about Lotus eSuite: it was, well, very cool, way (way) ahead of its time, and for a very brief period of time had the opportunity of dethroning Microsoft Office from its dominant position. Really. Well, maybe.

But it didn’t.

What went right? What went wrong?

Here is my perspective. Why do I have anything to say about it? Well, I was intimately involved with eSuite. You might even say I invented it.

Java and Platform Independence

In the bad old days of application development, you wrote an app in a language like C or C++ (or even assembler) which compiled/assembled to machine code. That code could only be executed by the specific type of processor in the box, like an Intel 80386. Moreover, your code had to interact with its environment — say, Windows — which meant it had to call upon system services, like displaying a button or a dialog box.

If you wanted to run your code on a different architecture, say a Motorola 68000-based Mac, you had to make massive changes to the source, because not all C compilers were alike, and because the underlying services offered by Windows and Mac were quite different. You coded a button on Windows very differently from one on MacOS or X-Windows. Hence at Lotus we had separate, large teams for Windows, OS/2, and Mac versions of the same product. (In fact, we were occasionally criticized for having spreadsheet products that looked like they came from different companies: the Mac, OS/2, and Windows versions of 1-2-3, built to conform to those platforms’ user interface standards, did look very different.)

Back to our story.

In 1995, Sun Microsystems released the first version of their new high-level programming language, Java. As the first language to compile to byte codes, instead of machine code, it had huge promise because, the theory went, you could “write once, run everywhere.” In other words, each platform – Windows, Mac, Sun, Unix (Linux was still nascent) – would have a runtime which could translate the byte codes to executable code appropriate for that device.

Perhaps even better, Java’s libraries (called the AWT, or Abstract Window Toolkit) also “abstracted” (wrapped) the underlying operating system services with a common API. The AWT’s function to create a button created a Windows button on Windows, a Mac button on MacOS, and so on.

Cool! So why was this more than just a neat technical achievement?

At the time, Microsoft largely dominated personal computing, and its competitors, principally Lotus and Sun, faced existential threats from the Redmond giant. (I’m not going to spend much time talking about how Microsoft achieved this position. There are many varied opinions. My own view, having worked at both Lotus and Microsoft, and thus having seen both companies from the inside, is that Microsoft simply outcompeted the others.)

In any event, many saw Java as a godsend, having the potential to release the industry from Microsoft’s stranglehold. In theory, you could write an application and it could run on anything you like. So who needed Windows? Office?

Browsers

Even cooler, Marc Andreesen’s Netscape Navigator introduced a Java runtime into version 2 of their browser, which at the time pretty much owned the marketplace. Microsoft’s Internet Explorer followed with Java support shortly thereafter.

Everybody at the time recognized that browser-based computing was going to be terribly significant, but web-based applications – especially dynamic, interactive user interfaces in the browser – were primitive (and ugly!) at best. HTML, was both very limited and extremely fluid at the time; the W3C had only been founded in 1994 and in any event the value of web standards had yet to be recognized. Browser developers, seeking to gain advantage, all created their own tags more or less willy-nilly. A very primitive form of JavaScript (confusingly, not at all the same as Java) was also introduced at this time but it couldn’t do much. And the beautiful renderings that CSS makes possible still lay in the future.

Anyway, Netscape and IE introduced an <applet> tag which let you embed (gulp) Java code in a web page. Sounded great at the time: code in a web page! And Netscape had browser versions for Windows, for Mac, for Sun workstations…you could write an applet and it would magically work on all of them. Wow!

A word on security (also kind of a new idea at the time, not widely understood and – in my view – universally underestimated). A web page could run Java in what was called a sandbox, meaning that it was actually isolated from the various aspects of the platform – the idea being you didn’t want to run a web page that deleted all the files on your PC, or scanned it for personal information.

I’ll have more to say about applet security in a moment.

Enter Your Hero

Somewhere around this time, being between projects, I started playing with Java. I had in my possession a chunk of source code that Jonathan Sachs, the original author of 1-2-3, had himself written as an experiment to test the then-new (to PCs: yes, purists, I know it had been around on Unix for years) C language. (How archaic that sounds today!) I have to say before going forward that Sachs’ code was just beautiful – elegant, readable, and as far as I could see, bug-free.

So I started porting (converting) it to Java. Now Java can trace its roots to C and C++ so the basics were fairly straightforward. However, I did have to rewrite the entire UI to the AWT, because 1-2-3/C, as it was called, was not coded for a graphical interface.

And…it worked!

I started showing it around to my friends at Lotus and ultimately to the senior managers, including the Co-CEOs, Jeff Papows and Mike Zisman, who saw it as a new way to compete against Microsoft.

Could we build a desktop productivity suite hosted in the browser that runs on all platforms and thus do an end-around around the evil Redmondians?

Things Get Complicated

Suddenly (or so it seemed to me) my little prototype had turned into a Big Corporate Initiative. Some of my friends and colleagues started playing with Java as well, and soon we had miniature versions of an email client, charting, word processing based on our thick client app Ami Pro, calendaring and scheduling based on Organizer, and presentation graphics based on Freelance Graphics.

And my colleague Doug Wilson, one of the 1-2-3 architects, came up with a brilliant way to integrate applets using a publish-and-subscribe pipeline called the InfoBus, the API to which we made public so anybody could write a Kona-compatible applet.

InfoBus was really an amazing innovation. With Infobus we were able to componentize our applications, letting users create what today would be called composite apps. The spreadsheet applet was separate from the chart applet but communicated through the Infobus – giving the illusion of a single, integrated application. So in the screenshot above you see the spreadsheet applet and the charting applet hosted on a web page.

Twenty-five years ago this was pretty awesome.

To make it all official, we had a name for our stuff: “Codename Kona,” we called it, playing off of the coffee theme of Java. (Get it?) Personally I loved this name and wanted it for the official product name…but there were issues. More on this in a moment.

And then a few things happened.

IBM

In June of 1995, IBM (heard of it?) bought Lotus. I heard the news on the radio driving in to our Cambridge, Massachusetts office, and was both horrified and relieved. Lotus – frankly – wasn’t doing all that well so getting bailed out was good; but IBM? That big, bureaucratic behemoth?

IBM purchased the company primarily for Notes, as their mainframe-based email system, Profs, was an abject failure in the marketplace, and Notes, far more technologically advanced, was doing fairly well. And since everybody needed email, owning the email system meant you owned the enterprise – at least that was the contention, and the investment thesis.

To my surprise, IBM showed far less interest in the desktop apps (which we’d named SmartSuite to compete with Office). They couldn’t care less about what was arguably one of the most valuable brands of the time – 1-2-3. But Kona fit into their networked applications strategy perfectly, which (I suppose) beat some of the alternatives at least.

The Network Computer

IBM had another strategy for beating Microsoft on the desktop, and again, Kona fit into it like a glove: the network computer. The NC, in essence, was a stripped-down PC that only ran enough system software to host a browser – no Windows, no Office, everything runs off the servers (where IBM with mainframes and AS/400’s ruled in the data center, and Sun dominated the web).

Oh, my. So we split up the teams: one focused on delivering Kona for browsers, the other, led by my late friend the great Alex Morrow, for the NC.

Lotusphere

Jeff and Mike, our co-CEOs, wanted to showcase Kona at Lotus’ annual developer convention, Lotusphere, held every winter at Disney World in Florida, at the Swan and Dolphin auditorium. Ten thousand people attended in person. (Hard to imagine these days.)

Including, by the way, the CEO of IBM, Lou Gerstner, and his directs.

We had great plans for the keynote address. We developed a script. We hired professional coaches to help us learn the finer points of public speaking. We rehearsed and rehearsed and rehearsed. Larry Roshfeld would do a brief introduction, then I would do a short demo on Windows, and then Lynne Capozzi would show the same software (“write once run anywhere,” remember?) on an NC.

Things went wrong.

First, my microphone failed. In front of this ocean of people I had to switch lavaliers: talk about embarrassing! (These days I tell people I’ve never been afraid of public speaking since; nothing that traumatic could ever happen again!).

But that wasn’t the worst.

In front of all those customers and executives, the NC crashed during poor Lynne’s demo. She handled it with remarkable grace and as I recall she rebooted and was able to complete the demo but talk about stress!

Bill and I

Now as competitive as Lotus and Microsoft were on the desktop, there were, surprisingly, areas of cooperation. For a time, the primary driver of Windows NT server sales was Lotus Notes, and so (again, for a very brief time) it behooved Microsoft to make NT work well with Notes.

And so Jeff, me, and several Notes developers hopped a plane – the IBM private jet, no less! – for a “summit conference” with Microsoft.

We spent a day in Building 8, then where Bill had his office. It was not my first time at Microsoft – I’d been there many times for briefings – but it was to be my first meeting with Bill. After several NT presentations he joined us during Charles Fitzgerald’s talk on Microsoft’s version of Java, called Visual J++ (following the Visual C++ branding). I’ll have more to say about J++ in a minute.

This being my space, I asked a lot of questions, and had a good dialogue with Charles. (I had more conversations with him over the years and always found him to be brilliant and insightful; read his blog Platfornomics, it’s great.) At one point, however, Bill leaned forward and pointedly asked, “Do you mean to tell me you’re writing serious apps in Java?”

To which I replied, “Well, yes.”

“You’re on drugs!” he snapped.

Thus ended my first interaction with the richest man in the world.

Launch

Nevertheless, perhaps because of IBM’s enormous leverage in the marketplace, customers expressed interest in Kona and we got a lot of positive press. Many resonated with the idea of networked applications that could run on a diverse set of hardware and operating systems.

And we were blessed with a superior team of technically talented individuals. Doug Wilson, Alex Morrow, Reed Sturtevant, Jeff Buxton, Mark Colan, Michael Welles, Phil Stanhope, and Jonathan Booth were just some of the amazing, top-tier folks that worked on Kona.

Kona.

As we drew closer to launch, the marketing team started thinking about what to officially name this thing. I – and actually most of the team including the marketing folks – favored Kona: slick, easy to remember, resonant with Java.

We couldn’t, for two reasons.

One: Sun claimed, by virtue of its trademarking of the Java name, that it owned all coffee-related names and they’d take us to court if we used “Kona.” I was incredulous. This was nuts! But we didn’t want to go to war with an ally, so…

Two: it turns out that in Portuguese “Kona” is a very obscene word, and our Lisbon team begged us not to use it. We all were forced to agree that, unlike Scott McNealy’s, this was a fair objection.

The marketing team came up with “eSuite,” which, truth be told, I hated. But I understood it: rumor had it that IBM, our new parent, had paid their advertising firm tens of millions of dollars for their internet brand, which centered around the use of the letter “e” — as in eCommerce and e-business. (Hey, this was 1995!) So our stuff had to support the brand. I guess that made sense.

So What Went Wrong?

eSuite was a beautiful, elegant set of applications created by an incredible team of talented developers, designers, testers, product management, and marketers. So why did it ultimately fail? Others may have their own explanations; these are mine.

Microsoft Got Java Right, None of the Others Did

Paradoxically, the best Java runtime – by far – was Microsoft’s. Sun had written a Java runtime and AWT for Windows but it used a high-level C++ framework called Microsoft Foundation Classes (MFC). MFC, which itself abstracted a lot of the complexity of the underlying windowing and input systems, among others) was great for building business apps (it was the C++ predecessor to Windows Forms, for the initiated). But it was absolutely wrong for platform-level code – the AWT on MFC was an abstraction on top of an abstraction: as a result, it was sssslllooowww. Similar story for Apple, and, believe it or not, for Sun workstations.

Microsoft on the other hand rewrote the Windows version of the AWT directly to Win32, in effect, to the metal. Hence it was way faster. And it re-engineered a lot of other areas of the runtime, such as Java’s garbage collector, making it faster and safer. Not only that, J++, as Microsoft’s version was called, was integrated into Microsoft’s IDE, Visual Studio, and took advantage of the latter’s excellent development, editing, and debugging tools – which no other vendor offered.

I attended the first JavaOne convention in San Francisco. Microsoft’s only session, which was scheduled (probably on purpose) late on the last day, featured an engineer going into these details in front of an SRO audience.

I remember thinking: okay, if you want the best Java, use Windows, but if you’re using Windows, why wouldn’t you just use Office?

Security

Now in fairness, the Java team was very focused on security; I mentioned the sandboxing notion that the applet environment enforced, which has since become a common paradigm. They rightly worried about applets making unauthorized accesses to system resources, like files (a good thing), so at first any access to these resources was prohibited. Later, in v1.1, they implemented a digital-signature-based approach to let developers create so-called “trusted” applets.

But that wasn’t all.

In effect, on load, the runtime simulated execution of the applet, checking every code path to make sure nothing untoward could possibly happen.

Imagine: you load a spreadsheet applet, and it simulates every possible recalculation path, every single @-function. Whew! Between network latency and this, load time was, well, awful.

The Network Computer was DOA

So, if you only want to run a browser, and you don’t need all the features of an operating system like Windows, you can strip down the hardware to make it cheap, right?

Nope.

I remember chatting with an IBM VP who explained the NC’s technical specs. I tried telling him that eSuite required at least some processing and graphics horsepower underneath, to no avail. In fact, as I tried to point out, browsers are demanding thick-client applications requiring all the capabilities of a modern computer.

(Chromebooks are the spiritual descendants of NCs but they’ve learned the lesson, typically having decent processors and full-fledged OSs underneath.)

Sun and Lotus Had Different Aspirations

In a word, Lotus wanted to use Java as a way to fight Microsoft on the office applications front. Basically, we wanted to contain Microsoft: they could have the OS and the development tools on Intel PCs, but we wanted a cross-platform applications that ran on Windows and everywhere else — which we believed would be huge competitive advantage against Office.

To achieve that Lotus needed Sun to be a software development company, a supplier – ironically, to behave a lot like Microsoft’s developer team did with its independent software vendors (ISVs) in fact, with tools, documentation, and developer relations teams.

Sun (as best as I could tell) wanted to be Microsoft, and its leadership seemed to relish the idea of a war (the animosity between Sun CEO Scott McNealy and Bill Gates was palpable). Sun couldn’t care less about allies, as the silly little skirmish over naming proved. But it clearly didn’t understand the types of applications we built, and certainly didn’t understand the expectations users had for their apps. Instead Sun changed course, focusing on the server with Java-based frameworks for server apps (the highly successful J2EE).

Perhaps somewhere along the line it made the business decision that it couldn’t afford to compete on both server and client – I don’t know. In any event the decline of the applet model opened the door to JavaScript, the dominant model today.

Eventually, and tragically, Microsoft abandoned Visual J++ and its vastly better runtime. Why? Some say that Microsoft’s version failed to pass Sun’s compliance tests; others, that Microsoft refused Sun’s onerous licensing demands. In any event, there was a lawsuit, Microsoft stopped work on J++ and some time later launched C#, a direct competitor to Java which has since surpassed it in popularity.

ActiveX

Not to be outdone, Microsoft introduced its own components-in-browsers architecture, called ActiveX. Unlike Java, ActiveX did not use a byte-code approach nor did it employ the code-simulation security strategy that applets had. As a result, ActiveX’s, as they were called, performed much better than applets — but they only ran on Windows. But the FUD (fear, uncertainty, and doubt) ActiveX created around Java applets was profound.

Lotus’ Priorities Changed

Lotus/IBM itself deprioritized its desktop application development in favor of Notes, which was believed to be a bigger growth market. Much as I admired Notes (I’d worked on it as well) I didn’t agree with the decision: Notes was expensive, it was a corporate sell, and had a long and often complicated sales cycle. I never believed we could “win” (whatever that meant) against Microsoft with Notes alone.

It was true that early on Exchange lagged behind Notes but it was also clear that Microsoft was laser-focused on Notes, so our advantage could only be temporary.

Someone told me that “Office is a $900 million business, SmartSuite is a $900 billion business, why fight tooth and nail in the trenches for every sale?” My mouth dropped open: why abandon almost a billion-dollar revenue stream? (Office is now around $60 billion in annual revenue, so staying in the game might have been good. Yes, hindsight.)

eSuite Was Ahead of its Time

Today, productivity applications in the browser are commonplace: you can run Office applications in browsers with remarkably high fidelity to the thick client versions. Google Docs offer similar, if more lightweight, capabilities.

Both of these run on a mature triad of browser technologies: HTML, JavaScript, and CSS. And the PCs and Macs that run these browsers sport processors with billions of transistors and rarely have less than 8 gigabytes of memory – hardly imaginable in the mid-1990s.

And eSuite depended upon secure, scalable server infrastructure conforming to broadly accepted standards, like authentication, and high-speed networks capable of delivering the apps and data.  

All that was yet to come. Many companies were yet to deploy networks, and those that had faced a plethora of standards — Novell, Lanman, Banyan, and so on. Few had opened their organizations to the internet.

eSuite’s Legacy

I hope you’re getting the idea that the era of eSuite was one of rapid innovation, of tectonic conflict, competition, and occasional opportunistic cooperation between personalities and corporations, all powered by teams of incredibly skilled developers in each. The swirling uncertainties of those times have largely coalesced today into well-accepted technology paradigms, which in many ways is to be applauded, as they make possible phenomenally useful and remarkable applications like Office Online and Google Docs (which, I’m told, is now called “GSuite”). In other ways – well, all that chaos was fun.

I wonder sometimes if eSuite might have seen more adoption had Lotus simply stuck to it more. To be fair, IBM, which had originally promised to remain “hands-off” of Lotus, increasingly focused on Notes and its internet successor, Domino; I’m guessing (I was gone by this time) that they saw Domino as their principal growth driver. Desktop apps were more or less on life support.

Still, by the early 2000s the concepts of web-based computing were becoming better understood: the concept of web services had been introduced; PC’s were more capable, and networks standardized on TCP/IP. Who knows?

Timing, they say, is everything.

Apparently one of the new buzzwords is composability, meaning everything from reorganizing (“pivoting”) your business quickly in response to changing market conditions to adding new technical capabilities to your applications as needed. As new features come online, the story goes, you should be able to seamlessly (that word!) add them to your applications as you need them, and ditch the ones you don’t need any more.

Now, let’s see, where O where have I heard this story before? DLLs, Java Applets, ActiveX, Enterprise JavaBeans, Service-Oriented Architecture, Service Provider Interfaces, the API Economy: it seems like every few years we have to rediscover how utterly cool modularity and (if we’re really chic) loose coupling are.

Technically, composability appears to mean something like a combination of SPIs and APIs. Microsoft touts the fact that it’s easy to add a FedEx module to Dynamics to enable shipping when it absolutely, positively has to be there overnight.

Cool.

Real composability, it seems to me, means a near-infinitely malleable product whose behavior can be adapted to any reasonable need.

How do you do that? (What does that even mean?)

Of course part of the answer involves a good, solid set of APIs to an application, documented, hopefully, with OpenAPI (nee Swagger) or something similar. Enough has been written about Why APIs Are Good that I’m not going to repeat their virtues.

But what about when you want to change, or augment, or even replace the core processing of an application feature? Well, of course many applications support events so you can know when they’re about to do something, or when they’ve done something.

But back in the day doing Lotus 1-2-3 my team and I decided we needed something more powerful. Our scripting language team (LotusScript) was demanding deep access to the product internals, and our addons like our Solver, even deeper ones. They needed to execute code in some cases before the relevant application code, in some cases after, for example, sideloading a file needed by the addon. And in certain cases – for example, loading a file type not supported by the original app – they needed to replace the existing code.

We had a pretty comprehensive set of APIs. But they didn’t solve the problem.

The Problem

Here’s the core idea: imagine a file load routine (this is pseudocode, so don’t get upset):

Pretty straightforward: parse the file extension and pass it off the right handler. No worries.

But what if you want to load a PDF? Or a text file? Or an MP3, for whatever reason? (Hey why not?)

Introducing the Event Manager

The idea of our Event Manager was simple: an addon could register for an event that happened before the core code ran, and/or an event that ran after the core code. In addition, the addon could return one of three values:

• Ran successfully
• Ran successfully, and bypass core code
• Error

In other words, something like this:

Here you can see the first thing that happens is any addons that have registered for the “OpenFile” Before-Event get notified, and can either ignore, augment – or replace – the core handling, and thus can load a wholly new file type, if desired. (EventManager.BeforeEvent() fans out the event to all registered addons.)

The After-Event has less options, for obvious reasons. It can be used for logging, or can be used to (say) load a shadow file (as many of the 1-2-3 addons did). In this case the addon has to handle any errors that occur as the core code may not understand the addons’ semantics.

Value

We found this pattern very useful in 1-2-3, so much so that I ported the concept to Lotus Notes some time after. In some ways, I think, this provides a good benchmark of what composability should really be.

A recent document allegedly leaked from the Kremlin accuses the Russian hierarchy of being based upon loyalty, not professionalism. “Accordingly,” the author writes, “the higher the level of leadership, the less reliable information they have.”

This raises some interesting questions: shouldn’t, after all, an organization have an inherent basis in loyalty across the levels of the hierarchy? If so, which is more important, competence (or professionalism) or loyalty?

Let’s spend a moment examining this dichotomy. I’ll posit – because I’ve seen them – in business there exist loyalty-centric organizations and competence-based organizations. Each has their merits, but each has serious weaknesses.

The Loyalty-Based Organization

Upon ascending to the American presidency, Donald Trump famously asked his staffers to swear their personal loyalty to him. Whether this was because he felt insecure in his new role, or threatened, or because he had some other motive will likely never be known.

Similarly, in the military, loyalty is a mandate: follow orders or people die.

Every manager wants his or her teams to have some amount of personal loyalty; that’s only human. Loyalty-based organizations take this to an extreme, however: the most loyal get the biggest raises, the juiciest assignments, and so on.

Still, such organizations have advantages. For example, a manager’s wish is followed – quickly – to the letter, which can be very satisfying (for the manager), and such organizations as a result often develop the reputation that they “get things done.”

However, there are some obvious downsides. A manager may hire less competent individuals – or favor them — if he or she deems them loyal, which results in the overall organizational capability to be lowered. Moreover, highly skilled employees will often recognize the existence of a clique – and leave. The work product of such a team will not infrequently be mediocre.

The Competence-Based Organization

At the other end of the spectrum, competence-based organizations place the highest values on skills, knowledge, and professionalism. The driving factor in such organizations is not coming up with an answer, but rather the best answer – often, regardless of how long it takes or whose feelings get hurt along the way.

Competence-based organizations typically seek employees with the highest degrees, with the most accomplishments, but often have trouble keeping them; who wants to stay in a place where analysis takes precedence over accomplishment, where argument is the order of the day? Moreover, what manager wants to stay where employees have no respect or loyalty?

The Ideal

Obviously, organizations should strive for some balance between the two; it’s vitally important for teams to distinguish the relative values of competence and loyalty and strive to create a corporate culture that supports both, one in which healthy, animated discussion of options has its place, in which decisions are made with an open mind – but they are made.

In the real world of course most organizations swing more to one side or the other. As an employee you should know which your organization is; and as a manager, which of the two management styles you’ve created, and perhaps think about making adjustments.

So What Do You Do?

Well, your first decision is do you want to stay in this organization?

Assuming the answer is yes, then if you’re on a loyalty-centric team, it’s probably a good idea to demonstrate loyalty, perhaps by complimenting your boss (“Good idea!”) every now and then, or giving him/her credit (and maybe overdoing it a bit) during a meeting with your boss’s boss — even for one of your ideas! That sort of sucking up can be distasteful, but, hey, you said you wanted to stay.

If you’re in a competence-based organization, put on a program manager hat every now and then and see if you can drive decisions or an action plan (“I see we’ve got just five minutes left in this meeting, what’s the next step?”).

Sometimes, incidentally, what appears to be a competence-based team isn’t really — it’s just that the manager is afraid to take responsibility for a decision. If that’s the case, consider making the decision yourself (assuming you’re okay with the risk). That way the manager can feel comfortable that there’s someone else to point at if things go south (like I say, only if you’re comfortable with taking the responsibility).

By Barry Briggs
[JUST A DRAFT RIGHT NOW!!]

Over the past few months I’ve been working with some old friends at the International Association of Software Architects (IASA) to try to figure out some way to quantitatively measure the value of software architecture. We’re trying to come up with answers to the following questions:

• Why is software architecture good (i.e., why do you need software architects?)
• How can you quantitatively assess an application or service?
• What makes a good software architect?

These are difficult questions, particularly when you compare software architecture with other fields. For example, it’s relatively easy to quantify the value of a Six Sigma process-improvement organization: you measure time, resources required, and costs of a process before optimization, and then after, and you have a solid measurement of value – one that is simply not possible with software architecture.

Why?

Well, on a net-new project, architecture is applied at the very beginning, so it’s difficult to know if the lack of it would have made any difference. Arguably, on a rewrite of a project, one could compare against some set of criteria how much better the new version works vis-à-vis the old one – but there are usually so many other factors in such a project that it’s essentially impossible to separate out the contribution architecture makes. For example, faster hardware or just plain better coding might be the reason the new app runs faster, not the fact that the new design is factored more effectively.

The Army Barracks

Perhaps an analogy can help us tease out how to think about these questions. Software architecture is often compared (poorly) against physical, building architecture – but let’s try to make the analysis a bit more constructive (pun intended).

Consider something as mundane as an army barracks. How would we measure the quality of its architecture?

I suppose there are lots of ways, but here are mine.

First and foremost, does it do the job for which it was intended? That is, does it provide enough room to house the required number of soldiers, does it provide appropriate storage, bathrooms, and showers for them? Is it well insulated and heated? In other words, does it meet the immediate “business need?” If not – well, you certainly couldn’t assess its architecture as good in any way.

Then we could ask many other questions, such as:

• Compliance with laws and standards, that is, building codes, Army regulations, local standards, and so on. Like business need, this one’s binary: if not compliant, no need to perform any additional evaluation.
  
• How resilient is it? Can it withstand a power failure, a Force 5 hurricane or (since this is a military installation) a direct hit by an artillery shell?
  
  
• How much load can it take? If there’s a general mobilization and much more space is needed, how many extra beds can it hold? 2x? 5x? 10x, in a pinch?
  
  
• New workloads. The Army mandates that barracks become coed. Can the facilities be quickly adapted – if at all – to support separate sleeping areas, bathrooms, etc.?
  
  
• How easy is it to add new features? For example, does it require a teardown to add air conditioning or can existing heating ducts be reused in the summer? How hard is it to install wi-fi hubs?
  
  
• What about new components? Say the Army mandates that every barracks has to have a ping-pong table, which entails a building addition. Can such a thing be done quickly with minimal disruption?
  
  
• Business continuity. Say the barracks does fall down in a storm. Are there sufficient facilities on the base – or on other bases – that the soldiers can rehoused?
  
  
• Aesthetics. OK, maybe this isn’t a good one for a barracks, but for other types of buildings – think I.M. Pei or Frank Lloyd Wright – aesthetics drive our view of good architecture.

You get the idea, and, hopefully, the analogy. In this case the value of good design – of architecture – is readily apparent.

Assessing Software Architecture

When we think about software architecture, we can apply similar criteria.

Business Need

If the software doesn’t satisfy business requirements, then – as we said above – it by definition cannot be “well-architected.” Determining how well software meets the need, however, can be an interesting and challenging discussion. For years, software development began with requirements documents, which could stretch to tens, hundreds, even thousands of pages; and managers would simply tick off the features that were implemented. (And as often as not by the time all the documented requirements were met, the business environment had changed, and the app was behind.)

With agile development, users are much more involved in development from the start, tweaking and mid-course-correcting the product during the development process. If there is a requirements document, it represents the starting point rather than a final statement – and this is good, because as the product takes shape, opportunities always present themselves, both to users and developers.

Still, how do we assess how well the product meets the need? Of course, one way is to ask users if they have the features they need; if not, something’s obviously missing.

But that’s not all.

Every line of code, every non-code artifact (e.g., images) should be traceable back to the business requirement. If there is a feature, somebody should be using it. Monitoring tools can help track which features are exercised and which are not. (The Zachman Framework was an early approach to documenting traceability.)

This applies to infrastructure as well. As infrastructure is increasingly documented through Infrastructure-as-Code (IaC) these Terraform or ARM or CloudFormation configurations should justify their choices: why – from a business perspective – this or that instance type is required because of expected load, SSD storage is needed because of anticipated IOPS.

Standards and Compliance

Like satisfying the business need, complying with relevant standards is binary: the software does or it doesn’t, and if it doesn’t, you’re done.

Now by standards we don’t mean “best practices” – we’ll talk about those in a moment. Rather, ensuring that personal data is anonymized in order to comply with GDPR, or that two-factor authentication against a central corporate provider (such as Active Directory) is used, or that only certain individuals have administrative privileges: where such standards are in place, they are mandatory, not complying places the organization at considerable risk, and thus the system cannot be assessed as well-architected.

However, best practices can be more flexible. For example, a cloud governance team may mandate the use of a particular cloud provider, a certain set of landing zones, a particular relational database, and so on. In rare cases exceptions may be granted. Here the goal of such guidelines is intended to speed development and ease operations, by removing the need for every development team to waste time selecting the appropriate provider or service and for operations teams to learn them all.

Granting such exceptions must be intentional, that is, careful analysis should uncover the core need for the exception; it should be documented and possibly, the best practice should be updated.

Defining Your Software Architecture Strategy

As is true with best practices, the definition and importance of other aspects of software architecture will necessarily vary from organization to organization. When developing architecture assessments, organizations should consider what their goals regarding software architecture are. For example, what are the relative priorities of:

• Application performance
• Application scalability
• Developer productivity
• Business continuity, including RTO/RPO
• Application visibility (observability) and self-healing
• Software extensibility
• Ease of upgrade
• Usability (e.g., is it mundane/functional or beautiful?)

For example, for non-multi-national organizations georedundancy or multi-regional replicas may not be necessary. Others may decide that the expense of active-active BC/DR solutions is too high.

Moreover, different applications will attach different levels of importance to these criteria. For example, an intranet application that shows cafeteria menus need hardly be georedundant or be built with microservices – it wouldn’t hurt, but perhaps resources could be devoted elsewhere!

Strategy to Principles to Assessment

Having defined the organization’s strategic goals from software architecture – i.e., what is good software architecture and why it’s necessary – actionable principles can be developed. By “actionable” we mean that developers can look at them and understand what must implemented, and perhaps even how.

For example, if a key strategic goal is that applications should be extensible, then a principle – that a developer can use – is that apps should have a REST API, documented with OpenAPI or the like.

A good starting point can be popular industry principles, such as the The Twelve-Factor App originally intended to guide the development of SaaS applications but in fact is very broadly applicable (shown below, via Wikipedia).

#	Factor	Description
I	Codebase	There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
II	Dependencies	All dependencies should be declared, with no implicit reliance on system tools or libraries.
III	Config	Configuration that varies between deployments should be stored in the environment.
IV	Backing services	All backing services are treated as attached resources and attached and detached by the execution environment.
V	Build, release, run	The delivery pipeline should strictly consist of build, release, run.
VI	Processes	Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
VII	Port binding	Self-contained services should make themselves available to other services by specified ports.
VIII	Concurrency	Concurrency is advocated by scaling individual processes.
IX	Disposability	Fast startup and shutdown are advocated for a more robust and resilient system.
X	Dev/Prod parity	All environments should be as similar as possible.
XI	Logs	Applications should produce logs as event streams and leave the execution environment to aggregate.
XII	Admin Processes	Any needed admin tasks should be kept in source control and packaged with the application.

We can learn several things from 12-Factor:

Principles Must be Easy to Understand, and Actionable

There are many ways of framing principles, of which 12-Factor is just one. What is key is that developers should intuitively understand what it means to implement them. For example, in 12-Factor, “any needed admin tasks should be kept in source control” easily translates to putting IaC artifacts in a GitHub repo.

Another common approach to documenting principles is called PADU, which stands for Preferred, Acceptable, Discouraged, and Unacceptable. PADU is attractive because it enables a range of options. For example, a “Preferred” approach to project management might be the use of an online Kanban board; “Acceptable” might be a form of Agile; use of waterfall methodology might be “Discouraged;” and using Excel for project management would be “Unacceptable.” Governance bodies (or the teams themselves) can then score themselves on a 0-3 basis and require a minimum score to deploy.

Principles Must Evolve

Organizations must recognize that owing to technical advances the principles may – and must – change over time. For example, the sixth “factor” above mandates that processes should be stateless; yet in today’s world it is increasingly possible, both from a technical and cost-effectiveness point of view to maintain state in business logic in certain circumstances.

Organizations Must Have Their Own Principles

Again, organizations may interpret industry principles according to their priorities and needs. Moreover they can – and should – add their own. For example, 12-Factor does not mention building zero-trust computing ecosystems and for many, if not most, this is essential.

Assessing Software Architecture

Having created a robust set of principles, it’s relatively straightforward to measure the degree to which a given product or service adheres to them. Many organizations use scorecards to rate software in an architecture review process, with minimum passing grades.

The Value of Software Architecture

A not-so-obvious conclusion from this exercise is that there are fundamentally three value propositions of applying software architecture strategies, principles, and assessments:

Usefulness, in other words, ensuring that the software does what its users want it to do, in terms of features, availability, and scale, to name a few.

Risk mitigation. Compliance with regulations and standards helps reduce the probability of a business or technical disaster.

Future-proofing, that is, enabling the product to grow both in terms of new features and the ability to exploit new technologies.

It’s exceedingly difficult to quantify the value of architecture (and architects), however. Yet it is intuitive that software cost estimation models such as Cocomo (Constructive Cost Model) which base estimates on line of code (specifically, e=a(KLOC)^b) could benefit — i.e., improve their accuracy — by including coefficients for architectural influence.

Many thanks to Miha Kralj of EPAM Systems, Jim Wilt of Best Buy, and Bill Wood of AWS for their comments and suggestions. Errors of course are my own.

Well, it’s that time of year when everybody writes their predictions for the year FWIW, which, given the track record of most such posts, probably isn’t much.

Here are mine … but first … a disclaimer: these are opinions which do not necessarily reflect those of anyone I work for, anyone I have worked for or will work for. Hell, with my ADD, they may not even represent my own opinions five minutes from now.