- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Failure, fairness and friends: development and video games
If you play video games, you may be aware of the Dark Souls series, or the genre of ‘Soulslike’ games. These games have common characteristics: they are third person action adventure games, usually (but not always) set in a fantasy world, where you fight an implacably hostile environment and enemies, including bosses who often tower above you. They have complex, obscure stories that you discover piece by piece, you level up by gathering resources (souls, or runes or something else) from the enemies you kill, and you lose those resources when you get killed - but you can regain them if you fight your way back to the place you died without getting killed. And they’re hard. Very hard.
i enjoy these games (with a few exceptions - ahem Sekiro ahem). Even though they are intense and frustrating, they are very rewarding when you manage to overcome challenges and get to the end. Moreover, they feel fair: when you die to a boss for the fifteenth time, you know that it was because you made a mistake: you dodged slightly too late, or you waited slightly too long to heal, or you pushed your luck a bit too far.
Features are like feathers: you never know how they will be used
We now know that many dinosaurs had feathers. However, this doesn’t mean that all feathered dinosaurs could fly: it is believed that feathers first evolved for insulation rather than flight, and developed over millions more years to provide lift as well as warmth.
Feathers are an example of exaptation: a term proposed by Stephen Jay Gould and Eilsabeth Vrba in 1982, to describe the phenomenon of something that evolved for one purpose, and has been adapted by evolution to serve another purpose. Other examples include the development of two of the bones that formed part of the reptilian jaw to become the malleus and incus, essential parts of the mammalian ear: we hear with bones that reptiles use to eat.
Exaptation is a useful concept in technology too, and we do not have to wait millions of years to see it in action: human ingenuity acts faster than evolution. For example, take the powerful computing devices we carry in our pockets and call ‘mobile phones’.
Technology estimates: unpredictable since 1823
In 1823, Charles Babbage was awarded £1,700 to build a machine known as Difference Engine 1, capable of automatically producing astronomical and mathematical tables. It was to be based on Babbage’s success in building Difference Engine 0, a smaller, prototype machine, which showed the potential of automatic calculation.
Nineteen years later, in 1842, after the budget had been spent ten times over, the project was abandoned. By this time, Babbage’s attention had shifted to an even more ambitious project, the Analytical Engine, which anticipated much of the computing architecture of modern, digital machines, including programs, memory and an arithmetic processing unit. Despite the contributions of another genius, Ada Lovelace, only a small part of the Analytical Engine had been built before Babbage died in 1871.
We should not disparage the work of Babbage and his colleagues for being incomplete: the Analytical Engine may be the best example ever of a machine being ahead of its time. To a modern computer engineer, the idea of building a mechanical digital computer out of brass and steel is audacious, to say the least. To a software engineer, the idea of developing computer programs, as Lovelace, without a machine to run them on, without the fundamentals of computing being settled - and without the modern programmer’s primary resources: the Internet, a search engine and online forums - is terrifying.
Try visiting a different layer of abstraction
I had a brush with assembly language over the Christmas break.
I’ve always counted myself fortunate that I started programming in the microcomputer era, when BASIC was the most common entry point for hobbyists, and that I got my first programming job when assembler programming was becoming rare, and languages such as COBOL were the norm.
BASIC and COBOL are regarded as old-fashioned now, but their core programming paradigm - a simplified, English-like syntax used to construct logic and manipulate variables - endures. However, I’ve always been aware of the assembly programming paradigm that involves loading, incrementing and comparing registers, and that it’s a lot closer to what is actually happening at a hardware level. I’ve also been aware that many large enterprises still depend on code written in assembly language, and have been grateful that I’ve never had to attempt to learn, read or debug it.