What seems to be the problem?

History is full of stories and actual situations from which we can learn a lot. Some are famous, others are known to only a few. But regardless, such stories and events can teach us lessons that can be applied many years later and in different aspects of life. I'd like to talk about one such story from our recent past. It has nothing to do with software engineering directly, but the lessons it teaches have an extensive application, especially in the software industry.

The Kremer Prize

The year when the story starts unfolding is 1959. Not much happened in the World that year. Castro came to power in Cuba and Alaska and Hawaii became the 49th and 50th state of the USA. That same year the Latvia born British industrialist and inventor Henry Kremer announced what later will be known as the Kremer prize. He decided that he will reward anyone that will manage to pass a simple flying test in a man-powered aircraft. The test was to fly almost 2.5 km in a figure-eight track, clearing 3-meter hurdles at the beginning and end. The starting amount of the reward was £5000. Adjusted for inflation that is north of £100.000 in today's worth.

Years passed, many people tried, but no one succeeded to win the prize. The test turned out to be not at all simple. Almost two decades later, in 1977, the aerodynamicist Paul MacCready decided to get involved. In that same year, he managed to be the first to pass the test and win the prize. At that time, the prize money had grown to £50.000. He also won the second Kremer prize worth £100.000 in 1979 after flying over the English channel. That is a bit over half a million-pound sterling adjusted for inflation.

Source: Wikimedia

The moral of the story here is not in the aircraft, the money or the prize itself. This story is interesting for another reason. It is how MacCready approached solving this problem in the first place. As soon as he started working on the task, he came to an important realization. All the other teams that tried to win the prize, they would spend a year or more on building the aircraft. At their first test, they would fail miserably, and after that, they would not have the time or the money to try again.

MacCready went with a different tactic. He figured out that he couldn't know all the possible requirements upfront. That's why he decided to design a plane that can be quickly built, rebuilt and modified. That allowed him to do a lot of attempts with as many different versions of the aircraft. On each attempt, he would discover a new and different requirement, implement it and then try again. He went step by step, solving problem by problem. The time when he finally passed the test, that was his 223 attempt. That is iterative development in the act. In 1977. It is almost as he had development sprints 18 years before Scrum was officially announced.

Complex Problems

MacCready won because he realized the complex nature of the task at the very beginning. He was dealing with something completely unknown. He knew that it was impossible to get things right on the first try because he simply didn't know all the things he needed to get right. He is quoted to have said, "The problem is, we don't know what the problem is.". For me, that is one of the most essential sentences within the complex domain of decision making and with that in the domain of software engineering. Figuratively speaking, that sentence defines what a complex problem is. This is what Snowden calls in his Cynefin framework, the unknown unknowns.

Since software delivery is a complex domain, MacCready's way is most often the best way to approach solving software engineering problems. Try, learn from the failures and take corrective actions next time. In most of today's commercial software products, it is impossible to identify all the problems upfront. The market is so dynamic, you can never know what it will require six months from now. Unfortunately, years after what MacCready did, the software industry still can't learn it's lessons. Waterfall-y, plan-a-lot-of-things-up-front projects are not yet a thing of the past.

Nobel laureate Gell-Mann said about MacCready that "He approaches nature and daily life with an innocent sense of wonder." That is how we need to approach building software every single day, with an open and inquisitive mind. Always ready to be surprised and to learn something new. And maybe most important of all, always ready and willing to fail so we can learn and become better.

On the cover photo is the Gossamer Condor, the human powered aircraft that MacCready won the prize with. Photo credit: https://en.wikipedia.org/wiki/MacCready_Gossamer_Condor#/media/File:Gossamer_Condor_-NARA-17497964(cropped).jpg

Sources

Igor Stojanovski

A full-time Software Engineer and an agile development proponent. I take interest in all stages of the development process, how to optimize and improve them.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.