When did Apollo 11 and IBM’s AI Code writing application succeed?
Lesson XIX from the lunar landings
When developing a new product, whether it’s the flagship product of a new startup, a new tool in the tool chest of a software vendor, an opensource project freshly published, or even a private utility developed in-house, there’s always a question — when do I know that my product is successful? This is not a commercial question, because that answer depends very much on the organization creating the product and its expectations. No, this is a technical question for the technical people who are creating or deploying the product — when do they know that the fruit of their labours has succeeded?
I’ll use two examples to answer this question. First, to commemorate the 55th anniversary of the launch of the first Moon landing (16th July 1969) I’ll use the Apollo 11 flight and next I’ll use a modern IBM product I’ve been working with as the second example.
Apollo 11 was launched on the 16th of July 1969, the ground computers orchestrating the mission were IBM mainframes and, in the heart of the mighty Saturn V rocket was a custom flight computer designed and constructed by IBM. Neil Armstrong and Buzz Aldrin landed on the Moon on the 20th of July, leaving Michael Collins to wait for them in orbit. On the 21st they left the Moon and returned to Earth on the 24th of July. A period President Nixon described as “the greatest week in the history of the world since the Creation”. During the course of that week, when would we say that Apollo 11 succeeded in its mission?
Fast forward to 2024 and watsonx Code Assistant for Red Hat Ansible Lightspeed is one of IBM and Red Hat’s newest products. It’s also quite a mouthful of a product name. What does the name mean?
In a nutshell, Red Hat Ansible is a solution that enables IT operators, sysadmins, and Site Reliability Engineers to automate much of their work. Instead of manually performing tasks, they create programmable playbooks that describe what needs to be done and how — and Ansible is responsible for performing that work.
watsonx Code Assistant is a family of IBM products which use Generative AI to convert instructions in normal language into the technical syntax of a programming language.
Lightspeed is the synergy of both these solutions which takes commands written in plain English such as “install a database on my server” or “deploy a new cluster” and converts them into the precise language Ansible needs to perform those tasks.
As defined in Red Hat’s landing page, watsonx Code Assistant for Ansible Lightspeed’s goal is to “help automation teams learn, create, and maintain Red Hat Ansible Automation Platform content more efficiently.” Helping teams create content more efficiently is slightly less romantic than walking on the Moon, though it is certainly more practical for day-to-day matters. For brevity, Ansible Lightspeed or just Lightspeed will be used for the rest of the article.
The office of the CIO in IBM supports all of IBM’s internal systems and we’ve been using Ansible Lightspeed ever since it was a not-yet-ready-for-primetime prototype.
When did each of these projects — the Apollo 11 Moon landing and Ansible Lightspeed in the IBM CIO office — achieve success?
As I’ve stated before, the Apollo program was fortunate to have a very specific and explicit target. In 1961, President Kennedy stated — “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth”. The interpretation is rather simple then — Apollo 11 succeeded, not when Armstrong and Aldrin walked on the Moon, but days later, when the entire crew returned safely to Earth. What’s the Ansible Lightspeed equivalent? For any product, the equivalent of returning to Earth safely would be when you know that the product has done what it’s supposed to do and you can confidently report to your peers and managers that it was worth the effort.
For us in the CIO, this point came at the end of the first quarter of using Lightspeed, when we could look back and report that Ansible Lightspeed had indeed helped us create Ansible playbooks more efficiently than before — it was indeed a success.
But neither of these answers feel satisfactory. They talk about success in retrospect (we know we succeeded earlier because we look back and see that we’ve done it) and not in the moment of success.
For Apollo 11 the trivial answer is that the mission succeeded when Neil Armstrong first stepped foot on the Moon and exclaimed “That’s one small step for [a] man, one giant leap for Mankind”. What’s the equivalent for Ansible Lightspeed? When was our “Moon Walk” with Lightspeed?
During our pilot stage of Lightspeed, we had allocated a number of experts to try out the product. Some were Ansible experts, some were unfamiliar with Ansible development. By the time Ansible Lightspeed was a proper product, we weren’t surprised to see the Ansible experts using it easily. The Moonwalk moment was seeing all the other people who were new to Lightspeed adopt the solution so quickly and easily. We set up a process to onboard people to Lightspeed and once we saw a large proportion of our Ansible development teams using Lightspeed — being more efficient with Lightspeed and being happy with what it offered — we could say that Lightspeed was a success and was giving us sustained business value.
But if you ask Neil Armstrong himself, what the most important part of the mission was, he wouldn’t talk about his first step. According to Armstrong, “Pilots take no special joy in walking. Pilots like flying”. For him, the moment he landed on the Moon and said “Houston, Tranquility base here, the Eagle has landed” was when Apollo 11 succeeded. For Armstrong, a steely-eyed engineer, success would have been the Lightspeed pilot program where we proved to our satisfaction that the recommendations Lightspeed was giving us were of a high quality and would be augmenting the work of our Ansible developers. This is when we got our first business value (developer efficiency) out of Lightspeed. From this perspective, scaling this out to the entire CIO organization is merely implementation.
Truth be told though, “Houston” was not the very first word spoken on the Moon. Moments earlier, as the spindly Eagle spacecraft touched the Moon, astronaut Buzz Aldrin called out “Contact Light!” followed by a flow of technical jargon, only understandable to the few engineers in Houston and unintelligible to the millions of regular humans listening. But at that moment of “Contact Light”, two humans were in contact with the Moon. This, then, is the equivalent of the early Proof of Concept we did together with IBM and Red Hat research before Ansible Lightspeed was ready to be published in the market. We knew, technically, that Lightspeed could do what it promised to do, but we needed to wait for it to be packaged for wider consumption before we could really claim success.
Speaking of wider consumption, there is one more marker of success for Apollo 11. During the Moon landing, Armstrong unveiled and read the message on a plaque attached to the lander spacecraft. “Here men from the planet Earth first set foot upon the Moon July 1969, A.D. We came in peace for all mankind”.
This is a message of success not for the people participating in the mission or watching it unfold live but for future generations. For a software product, this is the equivalent of a case study (or an article such as this), which documents the advantages of the product for others to benefit from. In the case of Lightspeed, the IBM CIO office published a case study based on the prototype version we used before the product was announced externally.
In short, the definition of success depends very much on what one means by “success” and who the audience of success is. For an executive, the success of a proof of concept may be meaningless, until the business value of more efficient development can be unlocked. On the other hand, for the engineer investigating the capabilities of a system, the matter of how to get other people to use it may be of scant interest compared to the technology itself.
The following table lists the types of successes described in this article and when both Apollo 11 and Ansible Lightspeed achieved each.
In short, the point at which you consider a project to be a success depends on your role and perspective in the organization. It might be enough to generate initial business value (a pilot program with a few experts using the product successfully) or it might only be months later when you have the confidence to formally report the benefits to the outside world.
But in general, the “One small step” moment is when you have realized sustained business value — when a significant population is using the project and benefiting from it.
With Ansible Lightspeed, we in the IBM CIO office have achieved all kinds of successes.
If you’re interested in how you can benefit from watsonx and watson Code Assistant, the following links will be of interest:
If you liked this article please clap here and share everywhere else!
And here’s a list of more of my articles:
For future lessons and articles, follow me here as Robert Barron or as @flyingbarron on Twitter and on Linkedin.
