The holidays have offered more time to catch up on my reading. Recently, I finished a book, Skunk Works: A Personal Memoir of My Years at Lockheed about the US Air Force Skunk Works projects. In my previous life, I was an Electrician on US Air Force fighter jets, specifically the F-15, so this book was fascinating about the challenges around building and fixing airplanes.
The book is impressive as is told from the engineers' perspective Ben Rich, who started as an engineer and later was responsible for the projects and eventually took over the Lockheed Skunk Works division. He was in charge of the teams building the famous F-117 Stealth Fighter, the U2 high altitude spy plane, and the SR-71 the fastest airplane still to date. Ben's management style was way ahead of the generation. He told his staff the following after taking over the Skunk Works division:
"I’ll be decisive in telling you what I want, then I’ll step out of your way and let you do it. I’ll take the crap from the big wheels, but if you screw up I want to hear it first." - Ben Rich
As I was reading the book, I couldn't help but notice the similarities between building concept airplanes and Minimum Viable Product (MVP) software development. The book covers a time of the 1950s to 1980s, which was before the computer designed and tested planes, but the project management and management style is still in practice today.
Interestingly enough, building concept airplanes is all about being quick. The engineering mandate was to be fast, efficient (more budget-wise), and reuse as many components off the shelf as possible from engines, avionics, and cockpits. Additionally, all engineers had to sit next to the airplane in the hangar where the development was taking place. I believe having the entire team sit next to the product; in this case, the aircraft helped inspire collaboration and new thinking. The goal of the concept aircraft was to prove the new design works and not all the functionality.
The development of the first stealth airplane, the F-117 was absolutely crazy! First, a Lockheed engineer read a published paper from a Russian Mathematician, which detailed the secret ingredients of stealth technology "The aircraft shape is more important than the size." Next, they worked out a new design concept, which reduces the radar size of the F-117 down from a flying bus to the size of a marble. Finally, they built two concept planes using existing technologies coupled with their new findings of Stealth design under budget and in record time beating out all their competitors and winning the contract to build the first Stealth airplane.
When we compare this to MVP software development, we take the same approach. Encourage the use of Open Source Software or existing software, allowing us to focus on the value-generating component of our software project, proving if the MVP is viable as quickly and efficiently as possible. By reusing "off the shelf" software, we decrease the amount of time required to bring an MVP to reality. Finally, we focus on being quick and testing our concept as soon as possible.
Now that the Stealth concept proved successful, it was time to build a real production-ready aircraft. The engineering team would now pick proper components for each area of the aircraft, including specialized designed engines reducing radar signatures, radar-absorbent paint, special cockpit, which blocked the pilot from radar view and custom tools to build the aircraft.
What came as a surprise is that each aircraft starts it's life at its lightest weight. Each iteration of the aircraft typically adds more weight, thus affecting the design with each iteration. It's critical in aircraft design to keep the first design as light as technically possible.
Just like software development is, we are usually adding more features and code, possibly adding technical debt to the "weight" of our initial MVP. It is essential to start as light as possible, as we will continue adding to the core of the product with each iteration.
Developing new Features
The feedback cycle is slightly different and more crucial to the pilots' lives. Several test pilots lost their lives, testing new features. The early test pilots ejected several times during their careers. After each flight, pilot debrief, and data analysis of the data collected determine what development was required. These new features for the planes continually kept the airplanes ahead of their competitors and from being shot down.
For example, the SR-71 engine inlets took one year of engineering before they were ready. After the first flights of the SR-71, the pilots reported the engines stalled and required several engineering iterations to rectify the issue. I don't know about you, but having an engine stall in an airplane doesn't sound too fun.
Luckily for most software development, we don't have people's lives depending upon our work. The software feedback cycle in product development is essential for new features or fixing bugs similar to aircraft development. Getting user feedback, collecting data, and making informed decisions is what drives the MVP product forward.
Recap the similarities between MVP Airplanes and Software Development
Our software development should now be speeding through the development process, 3x the speed of sound similar to the SR-71, and in Stealth mode to surprise our competitors. But to achieve the pace of development and time to market, we should adhere to the following:
- Use off the shelf tooling/software
- Be Efficient
- Be Fast, but don't break things (These are airplanes after all)
- Get all team members close to the product and working collaboratively
The book Skunk Works: A Personal Memoir of My Years at Lockheed was a fun read full of technical details, insider stories, and told from an interesting on the ground perspective. We don't often get to glimpse into the world of Skunk Works, but this was a treat. However, knowing that Stealth technology developed 40+ years ago has to have you wondering what is going on at Skunk Works today.