An allegory of development and operations
Long ago, three decades in the past, in a small dilapidated mill town to the north of Manchester, two grown ups and a child sat round a yellow Formica table in a council house, opening presents and wishing each other good cheer. A new dawn was to be heralded. New methods of progress about to be unleashed. Working class processes were about to become ‘digital’.
It was Christmas, 1985, cold clung to the windows, and the cats donned their new collars and hungrily ate their annual Christmas pilchards. It was a high tech house, with a colour TV and VHS player recently purchased, and a portable cassette player. Things were about to get better. I was eight years old.
My grandparents had noticed my burgeoning interest in computers, from my visits to a friend’s house, and they knew this would be big.
We didn’t have much money, so my Grandad quit smoking to save for the first purchase, something I will be eternally grateful for. The computer was presented on the morning of Christmas day.
Roland on the Ropes, The Pixel Empire
It’s not just for games, you have to code as well
My Grandma said. She was prescient to the future, and knew how easily distracted I was.
Yes, I played Roland on the Ropes, but, yes, I was going to code.
10 Print “Hello World”
20 Goto 10
Beautiful. I quickly graduated beyond this to coloured fonts, flashing screens, flashing borders, and nested loops. Lines of codes were getting to 10s per program.
After a while I was good, really good, having established two principles already:
- Pair programming — two chairs at the computer desk with my Grandad holding the coding magazines, taking turns to code, and checking each others code. We did dev, test and ops in our single multidisciplinary autonomous team. Velocity built steadily.
- Push button deployments — after the program was compiled to tape, just a single press of the Play button on the keyboard-integrated cassette player deployed my application directly to production, sometimes multiple deploys a day (none of that quarterly release nonsense)
It was time to take it to the next level. Extreme Programming (or what I liked to call, XP).
Photo by Simson Petrol on Unsplash
I sat down at the chair in front of my computer desk. I was extremely confident — wearing bermuda shorts, a bright purple t-shirt, and He-man slippers. I was in no way messing around.
My grandad liked to bet on horse racing, and he shared with me a two pronged approach: propel me to be an international computer star, and win big with William Hill. He realised he could combine these two things. But it was important to us both, that the full work was visible. We wanted to be agile. Following sprint planning, it was clear this would require 1000s of lines of code, and large data entry. I wasn’t going to play out for a while.
Four days of intense coding later, it was time to test the program. We didn’t have an AWS CLI, so I used the Amstrad CLI. I typed “Run”. Multiple errors in the code. It was at this point I realised micro-services would be better than monolithic code, with multiple code commits in small batch sizes automatically tested as they were integrated (this would have spotted coding errors early — mainly my Grandad’s).
The 90s
With my track record established, it was clear I would take Computer Science at high school. Dedicated computer science room. Archimedes computers with 3 1/4 floppy disks rather than tapes. Mecca.
Time to take it to the next level.
I was getting 10/10 and 20/20 in most tests. Awesome. My computer science teacher was great and built my confidence, he said I could be anything, even a Systems Analyst.
We coded. Our philosophy, deliver software as fast as possible — with one of our most important KPIs being the lead time from idea to production. There was no wall, quality was everything, and value in what we produced. Retention of pupils was high, attrition was low. Then Cyber
Captain Jean-Luc Picard, RollingStone
Our teacher was a gentleman — but he was bald — with only hair on the sides of his head, and for fourteen year old boys, ashamedly, that meant he was a target.
A friend of mine (I won’t name him, but he knows who he is) decided to write a virus. Every icon on the Archimedes would become a bald head, that he had made in a paint program. This wasn’t written in C/C++, or Assembly, but it was effective. The virus could spread like wildfire, just by inserting a floppy disk into the non network connected computer.
This was before devsecops, and before security procedures were implemented in the CICD pipeline. We were devops, but not devsecops.
We had flow, quality, questionable value, but were happy. We contained the virus, because we liked our teacher, and didn’t want to get expelled.
Exams were passed. A-levels were next. Introduce, Pascal. I coded, and now I was saving my code online, not on Github, but on Burycollegehub — it would do.
And effortlessly on to University. Pure computer science, C, Java, algorithms, very cheap beer… Error Code 1603: Java Update did not complete.
Quality and flow reduced. DevOps adoption was going through the change curve: shock, denial, acceptance, hiccups. It was time to containerise things, and I would make it to the end.
Choose your final assignment
My course tutor said.
A Conference organiser’s toolkit
I replied.
Java/JavaScript/HTML, and so the work commenced.
Conferences and Venues, The University of Manchester
I knew there were thousands of conference organisers in the world. And I knew that all lines of work were being digitally transformed at a rapid pace. This meant delivery of working software faster. This meant devops.
The potential market for my toolkit was large and as yet not disrupted. In the first few months, adoption of my toolkit was close to zero, just me and my course tutor, but I knew we were onto something. Before long, hits to my site would be up into high single digits.
The conference organisers weren’t ready for my software yet at a large scale, perhaps because we weren’t busdevops.
The degree was secured, then a job with Hewlett-Packard, the birth place of Silicon Valley and management by walking around — a principle I’ve always been proud of, and in terms of early devops, leading to building relationships between teams.
DevOps the Wall of Confusion, Microsoft Developer Network
Then a career spent managing across the wall, helping teams talk, helping project teams deliver, helping live service teams not suffer. I didn’t invent DevOps, but I should’ve.
And I was pretty handy at Roland on the Ropes.
The true account of DevOps is it was born in a talk by Andrew Shafer and Patrick Debois at a 2008 Agile conference (I wonder if they used a toolkit to arrange that?) — or probably before. Those people have my eternal respect, as they took two words and made them one, and working software could be delivered to production faster.
As for Roland, if you’ve read this far, you too can find out all about him on Wikipedia, or even better (without waiting for its 9 minutes to load) witness live game play action in this You Tube video.
Gary Watts
An Amstrad CPC, Wikipedia
If you enjoyed this please hit clap a few times.
You can follow me at hackernoon.com/@gary.sa.watts and twitter.com/@garysawatts
And for more articles from me:
What’s getting Agile down?_A productivity conundrum_hackernoon.com
Time to say farewell to Scrum?_Continual Delivery could blow it away_hackernoon.com
Mabl taught me how to become DevOps compliant_The moves sweeping the IT industry are fascinating to watch — DevOps, Site Reliability Engineering, Serverless, NoOps — …_hackernoon.com
DevOops, some common anti-patterns_Failing to bust those silos_hackernoon.com