Salon des Refusés 20172017-04-04, Brussels, Belgium
The lives we live are woven around the stories we tell. This is true of programmers as of all humans. Now the greatest of all stories are origin stories. In a first part, I will examine the origin stories of software, from simple tales of software creation to elaborate theories of software evolution. As I do, I will relate these stories to the tools they explain and the technological realities we bring about by following them. In a second part, I will conclude by reflecting on storytelling, on the progression of the above stories, and on what lies beyond. Stories are fun! And they subtly inform us. Let me tell you a good story...
Creationism, Evolutionism, Software Engineering, Tools, Storytelling, Logogony, Anthropodicy
If you have to structure software along informal design patterns rather than formal abstractions, you have run out of language (to quote Rich Hickey). But if you can’t recognize and discuss informal patterns in the structure of software development, you have not yet entered the realm of language with respect to software engineering.
Now the most powerful patterns about how humans behave are stories: they explain the behavior of a protagonist in terms of purposes and challenges, with causes and consequences for success and failure. Human brains are attuned to stories, whether implicit or explicit, and humans are wont to cast themselves into roles defined by stories. Furthermore, the most powerful stories are cosmogonies and theodicies: a cosmogony tells the origin of the existence of the Universe, and the role of God (or Gods) in this origin; a theodicy is a trial of those Gods, to explain the existence of Evil. This essay explores the most powerful stories about Software, logogonies and anthropodicies: a logogony tells the origin of the existence of Software, and the role of Man (or Men) in this origin; an anthropodicy is a trial of Man, to explain the existence of Bugs.
This essay should by no means be construed as either
insulting or vindicating anyone’s religious or irreligious beliefs
Indeed this essay makes no claim regarding the origins of Man
Still, this essay does make a claim:
that stories matter —
In the next two parts of this essay, I explore a gamut of
increasingly elaborate logogonies, and accompanying anthropodicies —
In a second part of this essay, I step back from the stories themselves, and discuss stories as a tool: what we can tell about them, how they shape our behavior. I then conclude with some remarks about what to expect from future stories.
How does software come into existence? Isn’t it obvious? If you ask a layman or a newbie, his explanation might be as follows:
At first the machine was uninitialized and blank;
then Man said: “Let Software be such” —
This simplest of stories is Software Creationism: it casts the programmer as a God Almighty outside and above the machine; the software is His creation, His proxy, embodied in the machine.
This belief not only comes naturally to non-programmers when confronted with the apparition of software; it was also historically the first logogony assumed; and it is still the tacit logogony underlying most undergraduate computer science education: in exercises and tests, assignments and projects, students are expected to produce a perfect solution to a perfect specification, from what is defined arbitrarily as “scratch”, whether on paper or on a restricted test machine. Their code is evaluated once by the teacher; it must stand alone and neither rely on any code by anyone else nor contribute to such.
No programming tools are necessary in this logogony; just pen and paper to write the perfect program, and a switchboard to insert the program into the machine. A perfect Programmer-God does not need tools: He transmits His perfect ideas to the machine directly in its memory in binary (or base ten, etc.). Programming the machine is best done directly in the machine’s language, for optimum representation of the God’s perfect idea.
Indeed, that’s not how software is written these days —
Software creation by a superior God is a beautiful story; however, anyone who ever endeavors to program soon realizes that programs seldom run perfectly at the first try, or even the second. Bad things happen: bugs, tyops, mismanipulations, cosmic rays, malfunctions, errors, even outright mistakes.
If the Programmer-God is perfect (at least once trained)
Sophisticated philosophers will claim that
while a perfect Programmer has a perfect program in mind,
its rendition onto an imperfect finite machine
is necessarily limited in form by physical constraints
But most people readily rush to the simplest explanation: the Devil.
A devil modifies software in a way counter to God’s intent.
Whether this Devil is an opposing force outside God,
a personality defect within God,
or a necessary artefact of the laws of Nature that God created
To fight the Devil,
the Programmer-God invents tools:
blinkenlights and punched cards (and adhesive tape) are used
so the Programmer-God may monitor as well as write the code.
Thus programs can be double checked, fixed, retried, stored,
despite any failures introduced by the Devil.
Programs must be read as well as written, decoded as well as coded,
and thus are born programming languages —
From a better (or less bad) theory of programming,
we thus get better (or less bad) tools —
Interestingly, anytime we find a new and hopefully better logogony,
we will always be able consider a variant of it
where some dark forces conspire to undo or corrupt
what the creative forces strive to achieve.
Thus, the idea of such opposing forces is a universal “mixin”
for logogonies, the devil mixin
While naive software creationism can adequately explain small programs, the theory quickly reaches its limits: large working programs just do not spring fully armed from the head of Man. In a more refined logogony, Man still has an essentially perfect idea of the Program, but imperfections of the Machine require creation in multiple, neatly organized layers:
On the first day, Man separated requirements from bugs. On the second day, Man divided the program into routines... On the seventh day, Man rested as the demo ran flawlessly.
This logogony leads to new conceptual tools: top-down design, software architecture in nice layers, flow-charts, the waterfall process. With it come divide-and-conquer algorithms. In terms of languages, it layers a FORmula TRANslator on top of Assembly.
Now, as an anthropodicy, the devil mixin applies to this story of Layered Creation of Software: at each of the steps, the Devil may cause mistakes. This leads to a slightly modified approach to layereed creation: iterating the waterfall process, until the code is stable enough, then start a new layer of work.
At first, Man wrote a single-file prototype.
Afterwards, Man worked on an alpha version, then a beta.
Eventually, Man released v1, v2, v3...
At last Man produced a stable version —
Each version is limited in resources and has to make tough choices and compromises that leave behind a layer of code fossils that you discover when you dig in the source code.
This suggests a new logogony, in which
Man cannot create entire software systems in one act,
if only because of the sheer amount of work required.
Instead Man creates software in many steps,
starting from foundations, building layers upon layers,
bootstrapping complex structures from simpler ones,
shaping tools and tool-making infrastructures,
replacing parts with better ones as the need and opportunity arises,
building scaffolding that is destroyed later
possibly leaving fossils along the way
In other words, Iterated Creation is but another name for...
Intelligent Design is the most common logogony among software engineers,
indeed implied by their very claimed title—
With this logogony are elaborated such tools and concepts as algebraic data structures and algorithms, operating systems, source code, compilers, compiler-compilers, build systems, modelling tools, hierarchically layered systems, the iterated waterfall process, release cycles, and all kinds of neat engineering practices.
Now of course, this logogony can be enhanced with the devil mixin, at which point new tools are engineered to counter the chaos introduced by the Devil: error messages, loggers, tracers and single-steppers to help locate bugs; line-editors to modify the Program; acceptance testing to validate It.
Another useful mixin for logogonies is the polytheism mixin. In this story modifier, there isn’t one Man, with one Master Intent and consequent actions, but a lot of Men (including Women), each having Their part in creating the Software, each with Their own intent and actions.
In some variants, it may be that these many Men are but facets of a same unique Man, who takes multiple roles to address the multi-faceted endeavor of Software design; or it may be that Man’s intent changes with time, or that Man is moody and has tantrums.
Man’s ways are impenetrable to Software, but enhanced theories of what Man is lead to the introduction of new tools. To address multiple programming Men, files are invented; as Men and Their work get organized in hierarchies, so are files hierarchically organized in (sub)directories. Source code comments and formal documentation serve to convey intent and content between Men. Machines are time-shared, operating systems grow to manage multiple users, and eventually multiple users at the same time, each running multiple processes. Communication protocols are developed to exchange data between machines, between machines and Men, between Men.
The devil mixin can also be combined with the polytheism mixin.
Each Man could have his Devil —
Intelligent Design was a much improved logogony compared to its predecessors;
but sooner or later, it too reaches limits
in its ability to describe reality accurately:
the design of most software is just really bad.
Whether you consider the end result or the process to get there,
you find that it shines neither by its efficiency nor by its elegance.
Not only are most prototypes no good at all,
most software projects are cancelled before they are shipped,
or scratched shortly thereafter —
The issue isn’t that errors creep in that corrupt the implementation of a perfect idea; the issue is that the idea was far from perfect to begin with. As far as creator gods go, Programmers are only so bright. Men have “bounded rationality”. In plain words, we are plain stupid. Thus, the next stepping stone on the way towards better logogonies is: Unintelligent design.
The Programmer-God may have an intent, but He’s a blind idiot who doesn’t quite know what it is he wants or how to achieve it. He not only makes gross mistakes, he goes on wild goose chases that lead nowhere, and sets impossible goals while ignoring obvious truths.
Tools to help Him design programs will thus include helpful messages from his compilers for error diagnostic and recovery. Their role is not to tell an intelligent programmer “the devil crept in while you weren’t looking, just have a look here, you can obviously see him and chase him”, it is to tell the unintelligent programmer “what you did was stupid, here is the explanation why”, for it would be hard for his limited intellect to figure it out all by himself. Syntax checking, type checking and various kinds of advanced semantic checking are invented to catch the more or less obvious errors and converge more quickly towards what the programmer would mean if only he were capable of forming coherent intent.
Interactive help, manuals and hints constantly remind Man of things that He should know better. Integrated development environments help Man play with the code and get faster answers as to whether or not his ideas make sense. Software interfaces are made idiot-proof by making languages more abstract and completing them with ample compile-time and run-time checking. Work is divided into “modules”, so that what limited intelligence there is can be focused in module implementation, whereas using modules through their public interfaces requires much less intelligence; complexity is thus managed away from stupid users. Good design ensures all choices that Man makes can be taken based on a shallow limited view of the world, the only kind that fits the programmer Man’s tiny brain. There is no shortage of imaginable tools and prosthetic devices to help Man cope with his mental disabilities; and these tools are themselves limited mainly by the inability of their own Manly programmers.
When a devil adds machine malfunction to operator dysfunction, testing becomes something to take seriously and systematically. When multiple gods are involved, the many resulting processes running at the same time must be protected from each other; the software is divided in many parts, that are tested separately; and contracts for what happens at their interface are attemptedly defined and enforced. Because the programmer gods cannot be trusted to remember all the issues with the software, some software must be used to systematically track those bugs and issues. When some of the programming Men are malicious, you’re glad they are idiots, too, and you bury them under the weight and complexity of security features that will catch each of the more obvious malicious types of behavior.
One trend can already be observed in all these stories: they each chip away at the supposed greatest of Man, identify more of His imperfections; yet, acknowledging these imperfections is precisely what enables the invention of tools to cope with these imperfections, which themselves enable the creation of greater software. Greater humility is what makes progress possible.
Also note that the tools tell the story, even when we don’t make the story explicit. Why do you use a typechecker? Because you make type errors. What if you don’t use a typechecker. You still make type errors and pay the price. Whatever stories you tell others to impress them, or tell yourself to boost your own ego, the tools you choose to use (or fail to use) tell a more honest story about yourself.
But how far does Man have to humiliate Himself before a truthful story emerges about the origins of Software? If Software isn’t the Triumph of the Will of Man, then what really is the driving Force behind Software? Before we can give answers to these question, we have to change our point of view...
Whether software is designed by intelligent or stupid Men, or by something else altogether, we may importantly understand that software changes to adapt to new circumstances: new goals, new programmers, new customers, new insight, new technologies, etc. And so we come to focus on the nature of this change through time, rather than just on its product at a given moment. Such is Software Lamarckism.
Filesystems may remember many versions of the files they hold, each with a different version number. Software releases are numbered too. Because many Men may be working at a time, a piece of software may exist along many different versions; moreover, these versions are not in a strict linear order, but may come in branches that sometimes diverge from each other, and sometimes merge back together. "Ports" from one language to another, and "inspiration" from one project to the next, are other ways that information is copied from one Software project to another.
To understand the differences introduced, whether they are intelligent, stupid or malicious and what to do of them, new tools compute differences between files. To merge the intelligent changes and the fixes to the stupid and malicious ones along the many different branches, tools are created to apply computed differences to branched files. Revision control and change management is born, and continuous backup remembers all previous versions of tracked files.
Lamarckism is not a complete theory of why and how change happens, but it introduces a useful focus on change. It is a Great Mixin that can be applied to all the previous logogonies, a starting point for more elaborate theories that will explain the development of software in the terms of this incremental process of change.
Unintelligent Design, while acknowledging Man’s stupidity at writing software in the small, still posits His grand design for building software in the large. How is this position defensible?
Lamarckism, by shifting the spotlight towards the change process, leads to asking why and how programmers lacking complete understanding choose to keep or change some or some other parts of the software. The immediate answer is that as Men write, they stumble upon good or bad features that they winnow by propagating the good and by eliminating the bad. The software writing process is thus some kind of artificial selection, under the careful, intelligent guidance of the Programmer-God. God impresses upon the process a definite direction, Progress, and otherwise lets software evolve organically in this divine order. Judging software being much easier than writing software, it is defensible for Man to be good at the former even though he’s bad at the latter. This logogony is Supernatural Selection.
With this logogony, new tools are selected into prominence. Prototyping tools help Man flesh out as many ideas as possible as quickly as possible, so he may select the correct ones. Formal specifications help define what software should be doing, without worry about how it will be doing it. Heuristic search algorithms use intelligently designed strategies to systematically explore spaces of potential solutions too large to be explored by the programmer themselves. The combination of these two approaches leads to declarative programming, whereby Man focuses on intent, and delegates implementation to the machine.
From one evaluation phase to the next, programs are transformed through systematic metaprograms. To prevent the devil from corrupting software, formal proofs are developed that perfectly exclude undesired behavior. To coordinate multiple Men, software modules separate interface from implementation, allowing for experimentation and adaptation separately in each part; rational developer communities are created, conferences are given, journals are published.
This whole approach has also been called the First Wave of Cybernetics. It combines an understanding of the natural dynamics of software with a faith in the ultimate power of an intelligent and purposeful Programmer-God, culminating with expert systems using explicit knowledge representation in an attempt to solve complex real-world problems.
The logogony of Supernatural Selection obviously suffers from the same shortcoming as did the theory of Intelligent Design before it, in that it supposes that the Programmer-God (or at least some of them) are supremely intelligent as regards judging the quality of software change. This shortcoming is obvious once the logogonies are articulated as clear theories, rather than adopted without a thought by mimetism or what seems to work. An immediate improvement over that logogony is thus to stop believing in Men as supremely intelligent Programmer-Gods. Men may guide the evolution of software, but their contribution to the process is hardly an overall intelligent coherent purpose; rather it is through a number of interventions based on partial knowledge, intuition, randomness, towards a progress that can be felt but not defined. Such is the theory of Teleological Evolution.
With the transition from intelligent guidance to unintelligent guidance, we are led to the appearance of new tools, that roughly correspond to the Second Wave of Cybernetics. Genetic Algorithms, supervised learning through neural networks, probabilistically approximately correct learning methods allow to mine information from large databases without any explicitly designed representation of knowledge. Weakly structured computations enable data manipulation despite limited understanding. At a smaller scale, programmers are satisfied with randomized algorithms that have good enough performance in practice despite having dreadful worst case guarantees. To protect from the Devil, checksums and probabilistic proofs can be more useful than unattainable formal proofs. To synchronize multiple Programmer-Gods, user communities come to prominence: users, though less proficient than developers, are those who possess the most direct distributed knowledge of what makes the software useful or not.
The logogony of Teleological Evolution loosens the strictures of Design or of Supernatural Selection, and opens the space for practical software solutions to problems beyond the full grasp of programmers. While it reckons the importance of reasonable endeavor, this importance is also de-emphasized; indeed, even reason can be seen as but a fast-track internal process of random production and selection inside the programmer’s mind, as guided by his godly intuition. In the end, Teleological Evolution embraces an unfathomable mystical intuition as the ultimate divine source of creation.
As far as logogonies go,
the notion of evolution under manly guidance
was an improvement over that of direct design by purposeful Men,
which was itself an improvement over the notion of direct creation.
But in each case, this was only pushing back one level
the assumption of a driving intent external to the world.
Real evolutionary theory does away with this assumption.
Survival of the fittest does not suppose
an external criterion of fitness to which living creatures are submitted;
rather, survival itself is the only criterion for survival,
tautological and merciless.
Survival is its own purpose:
those programs that survive—
The cumulative result of this natural selection is an evolutionary process
that favors bundles of traits that tend towards their own reproduction.
This freewheeling evolution necessitates no godly intervention,
neither by an intelligent conscience, nor by madmen.
More remarkably, programmers are no gods above it,
and their actions are no such interventions.
Programmers are but machines like others, bundles of self-reproducing traits
competing to exploit the resources of the universe.
As compared to other machines in this programming universe,
certainly programmers are unique and different
Natural Selection, unlike Supernatural Selection or Teleological Evolution, is what (software) darwinists mean when they speak of (software) “evolution”.
With this perspective on software development,
we gain new mental models for development processes.
We think of software in terms of self-sustaining systems,
that evolve and compete based on their ability to survive and spread.
We understand that the hosts and actors of this memetic competition
are men as well as machines, or even more so.
We may then notice that systems are never born big,
and that the only big systems that work are those
that were born small and evolved and grew in a way that
they were kept working at every step .
We relate the spread of ideas to the demographics
generations of humans and machines passing on
their forking and mingling traditions—
Models such as above mostly serve to filter out doomed business models and self-defeating attitudes when the model can explain how they go against reality. But they also lead to a few positive tools that actually help. A Third Wave of Cybernetics attempts to re-create artificial life and life-like phenomena through the emergence of behavior from many software agents. Unsupervised learning and tournament competitions yield results unreachable by supervised learning and explicit fitness functions. Understanding that the forces opposing creation act not through supernatural means but through the action of malicious or misguided humans, we achieve security through a mix of computer cryptography, growing networks of human trust, retaliating against bad behavior, and educating new people.
Software Darwinism provides a big picture
that puts haughty programmers down from their godly pedestal
and back into the muddy real world.
It doesn’t offer direct solutions to design problems so much
as it dispels our illusions about fake solutions
and unearned authorities.
No one is a god, above the others,
to predict what will work and dictate what to do;
our experts’ dreams are often but vain obsessions,
whereas some rare amateurs’ successful experiment may start a revolution.
Life is the ultimate judge—
Natural Selection may appear to look down on the world
as a soulless marketplace.
But it will only appear soulless if you imagine yourself in the seat
of that laissez-faire God above the world.
Face it: you’re no god, you’re not outside the world and above it.
There might be a God (or Gods),
who might or might not be intervening in this world—
The tools that matter are those that are available to you. Your resources are limited, and you should invest them wisely. Which tools will make you most productive personally? Opportunities are there to be seized; if not by you now, by someone else later. On the other hand, it may be too soon to invest in some ideas, and too late to invest in others; timing is key. Specialization will help, and can be a long-term investment that provides compound interests. As for cooperation with other non-gods, you can only go so far with your own efforts, and success lies in being able to leverage the efforts of other people. Which tools allow you to reuse as much as possible of these people’s efforts? Tools can be technical, or can be social. Not just software libraries, but software communities, software market niches, software business contracts. Of course, you always need some kind of exclusive resource to ensure a revenue stream; your combined proficiency, trustworthiness and time are ultimately the only such resource you have, and ample enough to live well if you can market it, though it will probably not make you super rich. On the devil side, intellectual frauds will try to have you adopt their bad ideas, and other scammers will try to divert your resources in their favor; you must learn to avoid them.
Evolution as an Inside Job restores the soul in the marketplace for software: yours. You’re the entrepreneur of your own life.
As you fully grasp the fact that all actors are individuals, not just yourself, you start taking into account incentive structures. Incentive structures will put you and your associates in a position to productively cooperate at your full potential, or to work at only a fraction of it; so carefully watch both your legal and business arrangements.
With a systematic view of incentives, you stress the importance of contracts and accountability as a way to structure human interaction, re-uniting liberty of means and responsibility for results in complex software arrangements. For instance service-level agreements will allow to robustly build larger, more complex structures than direct command chains. You may recognize the value of free markets as a way to organize people and to evaluate ideas, rewarding those able to invest their resources in the good ones rather than the bad ones. You may celebrate startup companies as light innovation structures with highly motivated personnel.
You may also consider long-term effects of licensing issues
on development ecosystems.
For instance, proprietary software has a definite short-term advantage
over free software
in capitalization, focus, coherence —
Thinking in terms of social evolution, of arms races from positive feedback, equilibria from negative feedback, invariants from limited resources, variants from energy sources and entropy sinks, can make you see what is invisible to those ignorant of the perspective.
From naive Instant Creationism to the darwinist view from Inside Evolution,
we can observe a story arc in these logogonies themselves:
Man is taken down from his pedestal as an Über-God above the machine,
until he becomes an underdog competing
as part of processes that vastly surpass him,
at the same level as machines.
Yet, each time Man’s image is humbled, Man himself is elevated,
as tools are then invented to address his identified weaknesses
The evolution of these stories can indeed be seen as an elaboration, whereby each step replaces an overly simplistic story that assumes power with a more accurate one that creates power. This teleological evolution towards more darwinistic stories being more accurate and more empowering could be a divine truth about our universe; or it could be merely a claim by the author of this essay, the validity of which could be less than universal; yet, even without being universal, its relevance to your own life could make it adaptive for you (for “us”?) to take it seriously.
In any case, we just stepped back from what the stories say to talking about the stories themselves. We went meta on the stories. Whereupon the topic of our story is storytelling.
Now, the tools previously described already exist; they have been created, engineered or selected, or they have emerged, without any of these logogonies being explicitly stated, much less used as conscious guides. Do these stories have any relevance, or are they but nice-sounding post-hoc rationalizations? Even if relevant, don’t they come too late to help invent those tools?
Daniel Dennett wrote: “There is no such thing as philosophy-free science;
there is only science whose philosophical baggage
is taken on board without examination.”
In software programming as in any other human endeavor,
not stating your assumptions
won’t save you from the consequences
of following them when they are erroneous—
Diagnosing how a “series of unfortunate events” is no accident but the necessary consequence of some previously invisible phenomenon is a necessary first step to properly addressing an issue. “Failing to plan is planning to fail.” If you assume an inadequately simplistic paradigm, you will keep attacking your problem with inadequate tools because you cannot even see how better tools apply to your case. You will waste significant human resources at unrewarding repetitive tasks at which humans are unreliable compared to the cheaper machines that you could have used; despite these sacrifices, or rather because of them, you will keep failing, until competition people using better paradigms drives you out.
The stories we live by are seldom told in so many words—
However, once you realize the stories are themselves subject to change,
then making them explicit, uncovering their plot holes
and feeling their discomfort can become the means, opportunity and motivation
for quitting (or wholly avoiding) a bad game and finding a better one.
Going meta about stories is then a tool for the group therapy
of dysfunctional software development teams,
of dysfunctional software ecosystems—
A story may good by itself—
If your problem is so simple that you grok it all and can write down a software solution in one breath, by all means, do it! Don’t follow a 12-step plan to software development to be rinsed and lathered along 30 iterations. If on the other hand you can’t fully understand the problem you’re tackling, if designing a solution is too hard for structured methods, then keep escalating the methods you use until you hopefully solve your problem. Generating random programs until a solution is found should be a last resort. Yet given proper biases in generation, cleverness in detection, and raw power, this resort might be made affordable, and find solutions where other methods fail.
Thus, when more elaborate stories are invented,
older, simpler stories don’t die out:
they each find their niche of validity,
where the cost of improving on them
is higher that the return on the improvement;
meanwhile, new stories cover new ground more so than claim known territory.
Interestingly, as stories inspire tools that increase man’s reach,
the domain of validity of older stories is expanded rather than narrowed.
Modern languages and IDEs indeed make it possible to instantly create
or systematically engineer programs that would previously have been
The question therefore isn’t to find a one-size-fits-all story, but to identify the story that best fits the situation at hand, which will make you most effective if you play the games it suggests.
Programmers could automate away a lot of the issues they face today if only they graduated from the paradigm of (Un)Intelligent Design to that of Supernatural Selection or better: Just giving up on having humans write software directly, and instead adopting more declarative and generative programming approaches could deal with better results and fewer efforts with (de)serialization, persistence, schemas and schema upgrades, replication, performance autotuning, representation selection, or maintenance coherence between multiple data representations, code layers, specifications, documentation and test files, etc. What more if they adopted the Inside View of Evolution, they would have a healthier approach to negotiating what the software should or shouldn’t be doing in the first place.
As the profession matures, software libraries and programming practices will spread that can be anticipated in terms of examining which logogony underlies some unsatisfactory practice, and imagining how a more elaborate logogony could enhance it.
For instance, unintelligent design brings us manual tests; lamarckism makes testing incremental; supernatural selection inspires generator-driven property checks; teleological evolution suggests whitebox fuzz testing; natural selection suggests bug bounties; and the inside view suggests paying attention to how management creates incentives towards better or worse code.
Intelligent design suggests type declarations; unintelligent design, type-checkers; lamarkism, type-based refactoring and schema versioning; supernatural selection, generic types and type inference; teleological evolution, automated learning of probabilistic type schemas for data extraction or activity monitoring; natural selection, learning with competing models and automated translation between type hierarchies; inside evolution, taking human factors, responsibilities and incentives into account in the modular design of class hierarchies and type systems.
The explicit application of logogonies to any particular topic immediately suggests a fertile research program to analyze existing practices and create new ones based on more elaborate logogonies.
Your software activities are unlikely to follow the "perfect" logogony; but that doesn’t mean that the story bringing the most tragic dysfunction in your life is your logogony. There are many stories about Software and about Man, that define your current behavior, the roles you play. If you work in a team (and you do), stories also define the way this team is organized, sets its goals and its means, the way each of its members sets their goals and means, the way people interact with each others inside and outside the team, etc. And the one story that you get most wrong, that is causing you the greatest pain or waste in your life, that you could benefit most from fixing... is for you to discover, examine, and replace. Logogonies were just the most spectacular way of illustrating the notion of stories and games we play; they are by no means the only interesting stories, or the stories most relevant to whichever important issue you’re dealing with at the moment. So, make the stories of your life explicit, identify those you’re living, and rewrite them, better!
One the other hand, if progress in how software is developped can be related to stories about software development, a question naturally arises: what are the next logogonies? Is the above “view from Inside Evolution” the be-all, end-all of programming paradigms? Is there nothing left but incremental refinement of existing concepts and tools? Or are there paradigms as radically advanced compared to software darwinism as software darwinism is compared its predecessors? Can one identify and adopt this paradigm early on, and thus get an edge over competition?
The simplest view about logogonies is that there will be no new ones, at least none that works. Our understanding of software development is mature; though there may be myriads of minor details to get right, the big picture is complete. This is Present Optimism: the “end of history” was reached, from there it’s smooth sailing and/or decline.
Of course, assuming the big picture about software will ever contain but finite understandable information, there will be a point when there is no room left for further paradigm improvements. Therefore Present Optimism will some day be true, about logogonies as about many things.
On the other hand, considering how new the field of software development is and how fast it has changed in just the last few years, it seems premature to declare that we fully understand how software is developed and will never find new deep insights. If our understanding of software development were to remain stagnant for, say, five to ten years, and all developers were to settle towards a finite set of well understood unchanging methods, then we could assert with much more confidence that indeed we have reached the acme of software development. But this hasn’t nearly happened yet, and the case for Present Optimism is rather slim.
A different kind of optimism, and a common idea regarding future logogonies has always been that computers will somehow surpass men in intelligence and take over the menial task of programming: they will be genies, who will grant your every software wishes, the details of which they can anticipate better than you can specify. This is Extreme Future Optimism, or Singulatarianism: the theory that soon(er or later), we’ll reach a Technological Millenium, or Singularity, when all our worries are taken away.
However, this Millenarianism is based on a misunderstanding, that is best dispelled by contrasting its equal and opposite misunderstanding: Millenarian Luddism, the claim that technology unless stopped will bring a bleak future where humans are reduced to misery as machines take all their jobs away. Hopefully the errors will cancel each other in a collision from which light will emerge.
Computers have replaced humans in many ways,
and will keep replacing them in more ways.
Computerized tools that replace humans while programming
are the heart of our story so far.
But automation does not destroy human jobs,
it only displaces jobs towards new areas not covered by tools.
Successful tools provide more satisfactions than before while reducing efforts.
More for less—
Of course, nobody prevents from using or sponsoring
a human-intensive way of programming
that declares some forms of machine assitance taboo.
There will always be a cottage industry of “brain made” software
just like there now is a cottage industry of “hand made” pottery
(still using tools, just neolithic ones).
But just like automation in other industries increased productivity
and made mankind vastly wealthier,
so will automation in programming increase productivity
and serve mankind—
The laws of Economics still apply. Which includes the laws of Evolution.
Indeed, the ideas behind Evolution were discovered
by historians as applied to economics,
long before they were ever applied to biology—
Machines can turn feats into chores, chores into menial tasks, menial tasks into assumable commodities. But they can neither create nor destroy the desire for ever more, ever greater satisfactions, the ability to adapt and work towards these satisfaction, and the individual accountability for the results: in other words, human drive, spirit and agency. As our past worries are cared for, we focus on loftier worries. Ultimately, only human parents create human jobs, and only illness and death destroy them; the rest is a matter of organizing existing human resources. The fear of Artificial Intelligence and claim of Human Supremacy is a lifeformist stance wrapped in the usual protectionist fallacies, and its narrowmindedness should inspire the same spite as racist or nationalist arguments before it.
Conversely, blind faith in Artificial Intelligence
is but another millenarian superstition—
However brighter or gloomier than today a future with artificial intelligences will be, bridging the gap between today and that future, if possible, won’t be achieved by hand-waving. It will require a paradigm shift that the cop out precisely aims at blanking out.
The legitimate cop out is not to assume knowledge but to admit ignorance: “my previous investigations didn’t lead to any firm conclusion to this question, and I don’t have enough combined care for the matter and trust in the remaining venues available for investigation to afford further investigation.”
The future promises many revolutions in how software will be written: between “artificial intelligence” and cyber-security arms race, mind-defying heuristics and automated formal methods, tomorrow’s technology is likely to obsolete today’s programming practices as hopelessly primitive and insecure. Can we make more precise predictions? It is difficult to make predictions, especially about the future (Karl Kristian Steincke). If you could provide an accurate functional description of what the future would bring, then this future would already be there, by the simple execution of this description as a plan. But we can make educated guesses. Here are mine...
Activities involving human intelligence have already started being replaced by computer automation. All of the programming tools we mentionned above are indeed forms of this replacement. The purpose of computers is to automate that which can be automated. This applies to all human activities, including “intellectual” activities. In particular this applies to software development itself.
One may hope that applying intelligence automation techniques at improving themselves may be self-catalytic: cumulative progress in machine intelligence leads to ever more progress in machine intelligence; bias towards systems that mutate better and faster leads to systems with even stronger bias toward mutating better and faster; pressure for higher value and lower costs leads to more valuable, cheaper automation that itself increases this pressure. Intelligence at writing machine learning software may be the most general kind of intelligence computers may have; and series of meta-level mutations can quickly bootstrap such intelligence in a positive feedback loop, until a phase transition is reached.
It is not immediately relevant whether a “Singularity” is ever reached whereby mankind is transcended, or whether mankind is as elaborate as intelligence gets, whether artificially intelligent autonomous agents ever emerge, or the only agents ever are humans and machines remain their props. That is not for any of us to decide, only to observe; maybe partake. Now, any progress we make is quantum, made of irreducible bits of information that take us closer to this goal, whether by big strides or tiny steps; and the amount of progress to reach whatever “intelligence” machines can embody is finite; therefore, if humans keep at it, they’ll reach their destination eventually, whether in decades, centuries, millenia or stranger aeons. What matters is that some road will be taken, and that those who stay behind will become irrelevant; what matters is that inasmuch as there is an inflexion point where we’ll reach quickly diminishing returns on investment in machine intelligence, this point seems to be well ahead of us; what matters is that we are within the part of the curve that accelerates.
Now is a time that you, personally, can have an impact. To maximize it, you may ask questions such as: What tools can you develop today that will best increase automation intelligence in the long run? Which generally applicable software methods are not currently applied to improving software development itself? What kind of architecture makes it easier to combine such methods and apply them to the improvement of software development itself? What essential aspects of more intelligent software are currently left unresearched?
All of us each have to make choices. I can see many opportunities: in architecting software that combines induction (machine learning) and deduction (algorithms); in recognizing that interaction with computers is dialogue not command, between unequals that have specific comparative advantages; in understanding of how the social organization of programmers and the architectural organization of programs are related via the feedback and incentive structures they induce.
But in the end, with this and other articles,
my choice will have been to try to reach out a happy few programmers
to open their minds to improving how they may think about programming,
and becoming assumed entrepreneurs of their own software life;
that they may control the internal evolution of their identity to adapt to the world,
rather than be the unconscious victims of an external evolution they can’t fathom