Programming as Theory Building

The name of this series, Software as Theory Building (SaTB), was inspired by the title of a thought-provoking paper titled Programming as Theory Building. The paper was written more than three decades ago by a highly-respected Computer Scientist named Peter Naur [1]. It was first published in 1985 and a 1992 reprint is freely available for reading as a scanned PDF.

At the time the paper was written, the prevailing wisdom conceived of computer programming as the production of computer programs, an activity where a programmer or teams of programmers produce text (code, docs) as the output. Naur argued that this conception of programming—the programming as production view—was misleading as it didn't adequately characterize what programming truly entails.

He proposed an alternative: the programming as theory-building view—that programming is in fact an activity that involves "achieving a certain kind of insight, a theory, of the matters at hand". He notes early in the paper that:

A more general background of the presentation is a conviction that it is important to have an appropriate understanding of what programming is. If our understanding is inappropriate we will misunderstand the difficulties that arise in the activity and our attempts to overcome them will give rise to conflicts and frustrations.

and although the paper contributed to a clearer understanding of what programming is among several practitioners, the true nature of programming and software in general is still misunderstood in numerous writings on the Internet.

Understanding How Software Evolves

An important premise that is often taken for granted by software practitioners is the question: how does software evolve?

A lot of practitioners speak of software evolution in terms of the One True Way™—how it ought to evolve—while ignoring lots of historical evidence on the myriad of ways on how software has evolved to meet the needs of individuals and businesses alike.

Hume's Guillotine: Is vs Ought

Hume's Guillotine is the name given to a centuries-old tension between two styles of reasoning: "is" versus "ought" based reasoning, first articulated in 1739 by David Hume in his A Treatise of Human Nature.

The is-ought fallacy is an especially enduring logical fallacy among engineers, myself included. For a long time, I didn't realize how pervasive it manifested in my thinking until I made the switch from engineering to product.

For Whom? An Engineering Audience

My primary goal with SaTB is to help other engineers learn to recognize the is-ought fallacy and related logical fallacies in their thinking.

My secondary goal is to increase our collective understanding of how software evolves, especially with the gradual shift to SaaS (Software as a Service) and broader trends presaged by Marc Andreessen's observation that "software is eating the world".

Why? Thinking Clearly

Software systems do not evolve in a vacuum. How a piece of software evolves is often shaped by its surrounding context or environment. For instance, to run a piece of software compiled for the PPC architecture, you will need access to a PPC environment—a computer system that can interpret PPC binaries. It doesn't really matter whether the computer system's underlying hardware is based on a physical PPC chip or a virtual one (in the form of a PPC emulator run on x86 hardware).

The availability of such an environment in the marketplace is in turn affected by the forces of demand and supply—aka market forces. Unlike forces in the realm of the physical sciences (specifically physics), market forces in the realm of business (specifically economics) are easy to miss because they are abstract—we often forget to account for them unless we apply conscious effort in our reasoning.

How? Revisiting the Past

Using real world examples from different industries, I plan to contrast theory (ought) with practice (is) over a series of essays. Each essay will revisit why certain software categories failed or succeeded by contrasting practitioners' expectation of how a software category should evolve with the different ways by which products under the category evolved in the presence of market forces.

It is my hope that, in exchange for reading SaTB essays, readers will gain clarity regarding how software evolves in a marketplace environment. Together, we will revisit past trends, reflect on current trends and guess at future trends in the software industry. I encourage you to join me on this fascinating journey by signing up for the newsletter!

Footnotes

1. Peter Naur is the 'N' in the BNF acronym which means Backus-Naur Form. BNF and the more widely used EBNF (Extended Backus–Naur Form) are a family of formal notations used to show that a phrase or sentence expressed in a language is valid i.e. grammatically correct or invalid. EBNF can be used with natural languages or computer programming languages as long as the syntax of the language is well-formed—the language's grammar rules are systematic.