Easy choice, right?
That’s what I thought back then in 2010, when I had to decide what my first job would be. I liked programming as a hobbyist, but that was about it. How could I make a living out of it, anyway? On the other hand, designing aircraft not only sounds like the sexiest job to many people, but from an engineer’s point of view, aircraft might just truly be the most interesting machines one would want to design. With that spirit in mind, I took a job in Airbus’ Future Projects department, after a six-month internship in Spain.
Aircraft design involves so many different disciplines and pieces of technology - a dream for a generalist engineer. Aircraft have to be optimized so much to be competitive. Minimizing their weight and drag is basically what justifies why Airbus, Boeing and the others have armies of engineers working on the same model for years of development. Of course, aircraft also have to be safe (and they are), but that’s not what sells the product. The only problem with optimizing aircraft, is that this work was already pretty much done during the 20th century. Nowadays, aircraft are so optimized that the only remaining lever of competitiveness has become upgrading the engines (needless to say that the engines are following the same trend of optimization as the aircraft). If you can come up with an idea leading to a one-percent saving of fuel consumption, you are basically a hero. People would kill for one percent. Of course, your idea would have to be perfectly flawless; that is: no issue with safety, no huge increase of drag to reduce weight (strutted wing), no huge increase of weight to reduce drag (high aspect-ratio wing), and no use of nonexistent magical materials. Most ideas are killed. Some quickly (grumpy expert, not in the mood); Some very very slowly (at a huge cost of many people working on them for years). Few new ideas make it to the aircraft, and that can be sometimes frustrating.
Additionally, “designing aircraft” is a rather fancy phrase for “running lots of calculations and having lots of meetings to converge towards a design meeting the specified targets”. I watched recently a TV-movie about Marcel Dassault, the great aircraft designer and businessman. The movie was interesting from the historical point of view. Only his character was depicted rather oddly. He looked more like a poet than an engineer. He would draw a ridiculously simple sketch on a piece of paper and then let his team of cliché socially-awkward engineers do the work, and there would be no problem because the sketch was beautiful (and that’s pretty much all that mattered). Although it might be true that a good idea can start as a sketch on a piece of paper, I doubt that an aircraft will fly well, simply because it is beautiful (however cute this idea might be). Especially today, aircraft fly well because they are optimized millimetrically, and have flown thousands of hours in a computer, before even existing.
The relationship of aeronautical engineers towards programming is interesting. It took me a few weeks to realize that there was something peculiar about it. Aeronautical engineers often think that programming is too low for them. The fact that most people didn’t know anything about it did not surprise me so much (after all, it might have been a generational thing). But I was surprised to see that nobody would even consider learning a little bit about it, given the huge importance of methods & tools in our daily business. Because indeed, software plays a central role in aircraft design. This industry has now for some time fully stepped in the computer age. When walking down an open-space at Airbus, you won’t see these armies of engineers bent over their large drawing boards anymore. Wind tunnel testing still exists, but it is more and more losing ground to Computational Fluid Dynamics (CFD), due to the much lower cost and higher productivity. However, that does not mean our software is always great. In fact, I sometimes found it ridiculously archaic. That, to me, was an issue, because software is productivity. Software can give you the power to deliver quickly an answer to an important question. In the best case scenario, people give their very best at work. In contrast, computers can rarely ever give their best, as we exploit only a very tiny percentage of what they could actually do. So, unlike people, computers have a large hidden potential of productivity. To exploit that potential we “just” need one thing: good software.
Bad software leads to bad answers - and/or slow response time. However, this simple fact does not seem to transpire in the company organization. I’d have expected lots of smart people coding great tools, but it seemed to be quite the opposite. Why? Simply because of the high cost of software development & maintenance. I list below some reasons why this cost would go up:
- As aeronautical engineering is not about writing code, this task is subcontracted. As a result, people who write code for us have no clue about what we do and what we need. They don’t know us personally and work in remote places (sometimes very remote). Therefore, they have to learn a lot of things from us, and we have to precisely specify what we want (which no aeronautical engineer is trained to do), and analyze what they deliver to give them a constant feedback.
- The people in charge of making the interface with software developers do not have any proper training. They often have no programming or IT skills, so they don’t understand the problems and questions raised by the subcontractors. They also cannot criticize the technical choices that they make.
- As nobody will criticize their technical decisions, the subcontractors are not that much challenged. So they stick to the technologies that they know best, not the technology that would lead to the best answer. Hell, they might as well pick the slowest solution: that’s more money coming in at the end of the project.
- You would expect the previous problem to be mitigated by competition between the various subcontracting firms. At least, we should be choosing the subcontractors offering the lowest price, right? Well, that’s a nice theory, but in practice, we often stick to the same subcontractors, for good and bad reasons. A good reason is that we know the people, and we don’t have to train them that much. I let you imagine bad reasons…
- People who have the power to decide if money will be spent on new tools do not use these tools anymore. They are simply too high up the hierarchy, and their only tools have become Excel & Powerpoint.
- A corollary of the previous point is that people managing money will spend it on shiny, fancy, well-presented projects. Unfortunately, the shiny new projects are proposed by those who have the time to prepare them, not by those who do the actual critical work for the company (simply because these guys have no time to describe what they need and want, and they are rarely asked).
Some aeronautical engineers see this and think: Damn, I really really badly need a piece of software to be written so I can do my job properly, but going through this way of working seems utterly inefficient. So they decide to go underground and write their own piece of software for their personal need. They know exactly what they need, and they choose a technical solution that, from their point of view, answers best to their need. In a vast majority of cases this choice will be bad, or what they need was already coded by someone else, and most certainly what they’ll end up doing won’t be compatible with the rest of the software that they use. In many, many cases, they’ll just create a monstrous Excel spreadsheet. I’ve even seen some primitive forms of CFD running in Excel (yes, aircraft fly thanks to a lot of Excel spreadsheets). Though Excel is not the worst evil: Of course, what you do in Excel is unmaintainable by someone other than yourself, but at least you can get a pretty complex program running in no time. In any case, they’ll end up choosing a technology that they know (not one they have to learn), so you also see a lot visual basic and Fortran, or in the best cases some Python and Matlab code.
When I started at Airbus, my prior knowledge of programming was limited. I had some academical and hobbyist skills. I remember coding some video games in Basic on my programmable calculator during long classes of high school. My masterpiece was a Role Playing Game (RPG), whose main character, “Dink Smallwood” (named after a real video game character from the 90s) would travel a land of dangers to achieve quests, defeat tough bosses and learn spells and buy weapons! As a young engineer, fresh out of the university, one of my first tasks in Airbus was to manage the development of one of our simulation tools. Of course, I was not expected to code anything. I just had to monitor the development made by our subcontractors. However, as our budget was limited, I also started myself coding in a number of new features. From then I never really stopped. Programming software was clearly never part of my annual objectives (and never became), but I did end up writing tens of thousands of lines of code in my time with Airbus.
Why did I write all this code? Well, for one it was hard to find anyone else to do it. But, I also found out something interesting, that I did not necessarily expect: This was rewarding. Unlike hunting for percentages of drag on the aircraft, designing software had a real immediate impact on my environment. When I started to produce good software we became more productive. We could do more with less, deliver faster and safer results, and use our brains for important problems, not monkey work. This felt useful, this felt good. The idea that my software would enable Airbus to deliver better aircraft just felt as good as actually designing them. In fact, it sort of felt better because this software might still run long after I would have left the company. I actually hate opposing aircraft design and software design. Everybody uses Excel for all sorts of things, and this is considered as part of aircraft design. It is, in fact, also software design: a spreadsheet is just a way to write a program in an easy and quick way. It is not very elegant and powerful, but it works. Arguing that aeronautical engineers should rather not write software is simply an encouragement to stick with the less elegant and powerful ways of working.
It is essential to understand that software can multiply productivity by large factors. The reason for this is that computational cost is nearly equal to zero. When you write one line of code, it is approximately the same cost to run it one time, or to run it billions of times. As aircraft design is about optimization, and optimization is about trial and error, it is natural to see that the more trials you can make, the more optimized your aircraft will be. Of course, some engineers hear this and tell you that they are much better at designing aircraft than computers, and of course, given the current state of their software, they are absolutely right. However, while they would then conclude that we did not need to invest in software, I concluded that we should massively invest in software, to invert that trend.
Big protests are currently taking place in the German part of Airbus, because unions have negotiated a deal to protect jobs and raise salaries, in exchange for a 5% yearly increase of productivity. One of the consequences, is that everyone now has to prove that his productivity has indeed increased by 5%. This is leading to funny situations, like workshops organized to find ideas to increase productivity further. To give an idea of the level of desperation, one measure was taken to forbid people from manually dialing phone numbers. From now on, they are forced to use their computer to dial automatically the numbers on their phones. Although this sounds hilarious, it is slightly frustrating to see that, for one, in spite of a limited imagination they do get a guaranteed pay raise every year, and for two, that nobody seems to get my previous point about software increasing productivity by large amounts.
Of course, it is fair to say that Airbus is no software company. That can explain to some extent why part of our software is archaic. However, it is interesting to look at the tremendous progress in software technology achieved around the world in the last two decades. Think about the impact that these innovations will have over other industries when they’ll catch-up. For instance, in the last two decades, software companies have progressively shifted desktop applications towards web applications. There are many advantages with web applications: Calculations run on the server; No compatibility issues between different OS; Less bugs; Updates are released very quickly; etc. However, at Airbus (and I imagine in other large non-software companies), software is still rarely developed in this fashion. I don’t think that this is the case because web applications wouldn’t suit us (I think they would be great). There are various reasons why this might be the case:
- Although examples are numerous (gmail, gdocs…), engineers don’t realize that this is an option for their own software.
- There’s obviously an overhead to run a web application (e.g. a server is needed).
- People being often in-between places, it is always comforting to know that you can access your applications without an internet connection.
- It is difficult to find software engineers who have the knowledge of both web application development, and engineering application development.
Sticking to desktop applications deprives us from many great innovations in software technology made in the last decade. But, it’s fine, we’ll get there. At some point, the gap in productivity will become simply too obvious, and we’ll take the step. By the way: there will be a great deal of money to be made when that step is taken.
One thing that web application can enable is true collaborative work. In some areas, software has already helped a lot. For example, Product Lifecycle Management (PLM) enables multiple engineers working with the same objects concurrently (e.g. to integrate various components in a fuselage). In other areas, this type of technology just hasn’t made it yet, and collaborative work is just a manager’s sweet dream. Working in parallel would systematically lead to inconsistent hypothesis taken by the different team members, because of the lack of a common model accessible concurrently. I have seen some attempts to establish such an approach through web applications, but it did not prove very promising, maybe because of the lack of quality of the software.
I have to conclude this, although there would be a lot more to say. I still think that designing aircraft is the sexiest thing. No questions about that. However, I think that the biggest innovations that are to come will be driven by software. Software will enable us to design new products much faster, and will enable the products to be smarter and more valuable. It could have, in a way, a bigger impact than using new materials, or more electrical architectures, or more efficient engines, etc… Some of my projects are based on the idea that there are large gaps to be filled with brilliant new software, in various places of this industry (and others). I hope that this analysis is not too far off, and that there is, indeed, value to be added (and money to be made) in this field.