- 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
Into the ever rising ocean of data
Data is, at the same time, the most mundane and most exciting aspect of computing.
It is mundane because of its origins in the world of folders and filing cabinets. In my first ever paid programming job, for a government department in the 1980s, the team I was part of was not called Information Technology (and certainly not Digital), but Automated Data Processing. And, while I was thrilled to get paid for writing code, the work we were doing was about as exciting as that title implies: we were doing the computing equivalent of shoveling coal from one pile to another (or moving records from one file to another). All of the data we were working already existed, in written paper records, in printed documents or even on micro-fiche. By creating Automated Data Processing systems, we were enabling data to be processed with greater speed and accuracy - but we were not creating new data.
Based on some informal surveys, I think that most people who have not had the chance to work in technical jobs, still think of data in this way. When we press ‘send’ on our mobile banking app, we imagine that the work that computers are doing is similar to the work that clerks would have done with printed ledgers many years ago: the data is hauled up from the memory of the computer, the number is read and sent out, some amendments may be made, and the data is sent back to its quiet resting place.
Shrinking space and time with dots and dashes
In 1844 Samuel Morse did two things that changed the world. He sent the first telegram in the USA, and he sent it using his famous Morse code. (Like many world changing inventions, the degree to which this was All His Own Work and the degree to which he drew from the work of others is disputed - not least by Morse). The telegraph shrank time and space for decades until it was superceded by other communications technologies: the last telegram was sent in the USA around 2006.
It may seem that the telegraph and Morse code are antiquated relics now, but I think that they help us understand an important part of The Round Trip question: networking. (This is part of a series of articles in which I attempt to answer, in non-technical terms, what happens when you press send on your mobile banking app. Or, more broadly: what does it mean to live in a world run by computers and made out of software?)
I must admit that I am not an expert in networking, and find the many network components that lie between the phone in my hand and the computer in my bank complex and difficult to understand and describe. I am hoping that simpler technology from another age can help me.
A balance between security, convenience . . . and legacy
We talk about the Stone Age, the Bronze Age and the Iron Age, and sometimes the Digital or Information Age. Perhaps one day we will talk about the Paper Age: the time when the world was run on systems and processes and information, but those systems and processes were manual, and the information was stored on paper.
Back in the Paper age, the way you proved your identity to your bank, whether to make a deposit, withdrawal or payment, was by signing a piece of paper: a paying in slip, a cheque or a letter. Today, that seems like an incredibly primitive and insecure method of authentication. Cheque books can be stolen, signatures can be easily forged, and anyone can write a letter. And, of course, banks were subject to fraud during the Paper age, to the extent that there are many slang terms for writing bad cheques: paper hanging, cheque kiting, bouncing cheques, hot cheques and so on. But many of these forms of fraud were exploiting the same feature that gave the banking system some measure of protection: it was slow. Cheques were physically transported to central sorting facilities where they were checked, reconciled and cleared. Letters could be queried. Signatures could be manually checked.
A question of identity
It happens in the blink of an eye. You press the tip of your finger against your phone. A capacitative sensor determines the pattern of ridges and valleys in your fingeprint . An algorithm matches the pattern against a digital representation stored in a secure enclave on your mobile device. If it finds a match, it unlocks your phone (or does whatever other task you were attempting to authorise).
There are other means of authentication, such as facial recognition, PIN codes and passwords, but I think that fingerprint recognition is particularly interesting because it illustrates important differences between the ways that humans and machines and systems deal with identity. (By ‘systems’ I mean all formal, process driven methods of interaction - not just those implemented in software on computers.)
When humans think about identity we think about an individual, a person. When we say that we know someone, we mean that we know many things about them: not just their name and their profession, but aspects of their behaviour and personality. It is remarkable how quickly we form an impression of a person: even if we have only shaken hands and shared a meeting room with someone for an hour or two, we come away with some idea of what they are like. (Of course, our impressions are also subject to bias and preconceptions: the speed with which we form ideas about others is not always a good thing.) When we encounter that person again, we don’t typically feel that they need to prove their identity. We recognise them.
It is in the nature of software to be broken
‘Why don’t they just write the code properly? Why can’t they just get it right first time?’
I’ve heard these sentences spoken several times in a professional context by non-technical project managers wondering why the testing phase of a project (or a sprint, or a release) is taking so long.
Even if you’re not a project manager working on a development project, you may have similar questions when you encounter software problems in your normal daily life. Why does your laptop always need updates? Why is the web site you want to use down yet again? Why are big budget games full of bugs when they are first released?
If you have ever written code for a living you may be simultaneously exasperated and embarrassed by these reactions. Embarrassed because you recognise that too much code which makes it to production contains too many bugs which should have been detected and eliminated in testing. Exasperated because comments such as ‘Why don’t they just get it right first time?’ fundamentally misrepresent the experience of writing software.
The round trip question: if you want to understand the world, learn to code
COBOL turned 60 in 2019. Happy birthday COBOL! Python turned 30 this year. Happy birthday Python!
If you work in a large company, you have probably heard of COBOL - often in hushed tones, referring to ancient, giant systems that are held in a special facility somewhere out of sight, tended to by people steeped in ancient wisdom. You may also have heard people speak about Python, often in excited tones, referring to new disciplines such as data science and machine learning, exercised by smart new people fresh out of college.
The comparative age of COBOL and Python may be surprising to anyone who has never had the chance to write code: COBOL is older than Python, but they are both so old that they have been around longer than most people today have been working. If you do write code then you know that, while they may have significant differences, at root these languages are more similar than they are different. They both use the same logical constructs to manipulate data.
The round trip question: what is a computer?
It is the secret that everybody knows: a story which has rightly become a legend. During the Second World War, Alan Turing and a team at Bletchley Park invented the computer in order to crack the Enigma code, shortening the war and saving millions of lives. Turing was persecuted for his sexuality and died tragically, to be recognised as a national hero decades later.
Except that, while Turing deserves all the acclaim we can give him, part of this story is wrong. Turing did not invent the computer to crack the Enigma code. The difference between the device used for Enigma, the Bombe, and the real first computer, Colossus, as well as the original thinking that Turing did before the war, help us understand what makes a computer a computer, and why they make such a difference to the world.
The round trip question: a tale of two computers
Let’s start with a problem. You think some bills have just been paid out of your account. You want to check how much money you have left. You have a computer in your hand - your mobile phone - but that computer does not currently know your balance. There is at least one computer that does know your balance, but it does not belong to you, and it sits in a large building hundreds of miles away. How does the number that represents your balance get from your bank’s computer to the mobile phone in your hand?
This is one of a series of articles which explores how we use computers to run the world by considering the round trip question: what happens when we press a button on a mobile banking app which tells it to do something with our money?
Simply by virtue of being computers, the phone in your hand and the machine in your bank have a lot of similarities. For now, though, I’d like to explore their differences, as those differences are what makes the round trip question interesting.
The round trip question: a duty to explain
Something has been bothering me: I have been designing, building and running computer systems for over thirty years, and believe that the explosive growth of information technology in that time is a net good for the world. At the same time, I have observed a growing gap in understanding between the people who build and run technology for a living and the people who use it. Information technology touches more people’s lives more deeply every day - yet is increasingly difficult to understand.
I sometimes test this feeling by asking what I call ‘the round trip question’. The question is: when you hit a button on your mobile banking app which tells it to do something (get your balance, make a payment, or some other function), what do you imagine happens? (It doesn’t have to be banking, but it’s the industry I happen to have worked in for longest.)
Use both feet to step on to the cloud
The early days of Cloud adoption in many large companies are dominated by the creation of Landing Zones (LZs). This term can mean a lot of things, but encapsulates the set of configuration, controls and instrumentation a company uses to set up a Cloud platform to its liking and needs. If a Cloud platform is like an apartment block, setting up your LZs is like moving your furniture in, putting the locks on the doors and arranging your utilities. You may have people to help you (integrators and consultants in the Cloud, moving companies and interior designers for your apartment), but you are the one who is going to live there.
Many companies struggle in this early stage, as it can feel like they are making their most important decisions at the time they have the least expertise. I have seen this lead to two anti-patterns: the free-for-all and the gold-plated LZ.
Who are you optimising for?
A long time ago, one of my colleagues gave me a reality check. I was working as an architect and he was working as a methods specialist. I thought that our jobs were important, but he reminded me what was really important when he said, ‘We’re here to deliver working software. If we’re not doing that directly, we have to ask whether we’re doing our best for the people who do deliver working software.’
A few months ago, I wrote an article which asked the question, ‘what are you optimising for?’ when attempting Cloud transformation. Today I’d like to ask a question which I think is even more important: ‘who are you optimising for?’
Architecture year one: measuring success
I have a flippant answer when asked how to measure the success of an architecture team: just check how often your phone is ringing. (I realise that this dates my advice - please substitute ringing phones for the messaging app of your choice.) If you and your team are in demand, if you are the first call whenever your company faces a big challenge or opportunity, then you are doing something right. If your phone (or messaging app) is silent, if you have to push to insert yourself into the room with tough problems, then you have more work to do.
However, recently I was talking to a friend and colleague who has just taken on a Chief Architect role in a new company, and who is attempting to design measures of success for their team. In that conversation, I realised that we needed to come up with something a bit more sophisticated than the number of messages on your phone.