Status: in progress
As the scope and complexity of software increases, so does the potential for harm. The failure of an important software system is now comparable to that of large physical structures such as dams or bridges. Despite this, there is a distinct lack of true engineering practice in the software industry. Software professionals wear the title of "software engineer", but the average quality of software products is generally low and prone to failure.
The purpose of this document is to offer an big-picture analysis on the purpose of software, and a vision for how it can support human flourishing for the next 1000 years or more. This is not a manifesto. This document promotes ideas but not idealogies. I have tried to write this document such that deep knowledge on software and hardware should not be necessary.
In order to talk about software we should first define it. For this document I will define software as a contract between human intention and machine capability. To explain this, take the following pseudo-code snippet for example:
print(1 + 1)
This program computes the sum of 1 and 1 and displays this somewhere. The software here is not the text itself. Text is merely a convenient representation for an expression of machine abilities arranged against human desires. Observe that this program could be fulfilled by many different existing and future physical machines. For all such machines we would expect to see "2" displayed to the user. The program above is abstract: there is no specification for how the value 1 should be internally represented, or how the value of 2 should be formatted when printed to the user. Similarly to legal contracts, contracts between users and machines can be terse or verbose. In cases where contracts contain ambiguity (such as verbal agreements), there is typically more work required in determining the interpretation of the contract. Such is the case in software, whereby certain checks and balances can be deferred to the run time rather than defined ahead of time.
Software projects can go very wrong. Some engineering methodologies such as Kanban have been co-opted from manufacturing into software. While they have seen wide adoption, these methologies have largely failed to increase the overall standard of software.
Producing software is expensive in energy and by extension monetary terms.
Some software written today will run, largely unaltered, fifty years from now. This is not a radical idea, given that there are already COBOL systems that have operated for 60 years. Despite this, most software engineers do not assume that their.
Until this point I have been presenting the case that software robustness and longetivity are .