‘System architecting under extreme circumstances’ is how you could describe Guido de Boer’s job at Mapper over the past fourteen years. Part 2 in a series of interviews in which he shares with Bits&Chips his unconventional view on developing systems, in the run-up to his keynote at the Dutch System Architecting Conference on 20 June.
Guido de Boer likes to reconsider stuck habits, to ask questions about generally accepted truths. In a conversation with him, we regularly come across the quirks and instincts of technicians. They’re often very creative, but at the same time, they’re trapped in their own somewhat religious, centralist worldview. This manifests itself in their tendency to want to control everything and their desire for a total overview. Engineers want to think about what should happen at any time in the machine. They want to come up with the entire software structure and determine in detail how everything works mechanically.
Nonsense, De Boer says: “That shouldn’t be done at all. It’s about making agreements and thinking. What abstraction am I in? If I’m the boss of this box, who should I make arrangements with? When the wafer stage is my responsibility, I have to come to an agreement with the guy of the wafer handler: cut the agreement in two, archive it and stick to it. It’s not at all important if there are a hundred cables or ten computers inside.”
Your people were completely free to choose the technology they thought was good within those agreements?
“The point is that it just doesn’t matter. Agree to an interface, cut it in half. System engineering at every level was important to us at Mapper. We were busy building that machine all the time. We tackled that problem in ten pieces. After that, you’re very clear about the interfaces, the requirements and the acceptance requirements for those ten parts. I expected everyone to cut their problem in ten parts again. Those pieces make agreements with each other again and that’s how we integrated it. If you think carefully about those modules, then they’re also easy to test and maintain. If you approach it that way, you’ll never build one major software release. Why would you? You don’t need to put all machine software in one computer system or run it on one operating system. The same goes for mechanics. We had three mechanical design packages.”
You didn’t care?
“In fact, I didn’t want just one. Because then you’re constantly fighting with that one holy way. Certainly in the Netherlands, monodisciplinary engineers all have an almost religious belief. ‘We have to work with Solidworks!’ Then we all use the same library and we can reuse our bolts. Forget about it. Just copy it or draw it again. The same goes for software reuse. There’s a lot of literature about that, but there’s no need for it.”
Many companies strive for their technicians to use the same software tools and systems as much as possible and the purchasing department arranges this.
“One thing has always been certain for me. If Mapper were to get a purchasing department, I would be gone. For me, this is the moment a company is on the wrong track. I’m serious. Everyone at Mapper knew my point of view on this. My office was overrun by people who noticed that the same roll of copper wire had been ordered in three places: why didn’t we coordinate this and bought only one? Simple: if you have to request a quote for that copper wire role, everyone will just wait for each other. It’s something that makes me puke. Look at the municipalities, hospitals and schools that had to merge in the Netherlands. The big promise was that I would have great efficiency benefits, but there’s no evidence for that. There’s evidence that it’s disadvantageous, although it’s statistically difficult to make firm statements about costs and efficiency in such organizations.”
De Boer encouraged this philosophy at Mapper: no reuse, especially no commonality. “That’s the biggest nonsense there is. Cynically, commonality is the software department’s thing. There’s no evidence for the usefulness of software reuse. Gerrit Muller at ASML made me think about that. I was the manager of the software architects there in the late 1990s and they did no different. Muller was strongly against that at the time. He said: reuse is nonsense. His rule was: you only need to think about it after you’ve made the same thing three times. I learned a lot from his views.”
Relativizing: “Objectively speaking, I can’t say whether it’s good or bad. In that sense, I simply adhere to one of the religions in the technical world.”
According to De Boer, what’s useful and where people learn and use a lot from each other is the internet forum Stack Overflow.
“I use that a lot. It’s great. On Stack Overflow, you can find how you can solve something in, for example, Python and Matlab. The website applies statistics on contributions and comments: over time, green ticks appear on the good solutions. This way, you can see which tips are the right ones. Just type in Google what you want to program and you will always get a Stack Overflow hit. For example, ‘3D array plotting’ immediately yields hits. You can see that Mathworks is also starting that now. This has grown organically by people who want to share and use each other. It works.”
“I have to admit, I have a slight religious resistance to people who want to design databases. If a group of managers or politicians solve a problem, then usually a database comes out. See the electronic patient database in the Netherlands. Whenever a disaster happens, you always see the same reaction: social parties come together and the solution is a database – because we have to work together and share data. That, of course, doesn’t work. Stack Overflow does. There’s a balance between the time it takes to put something in and get something back.”
What if we had a Stack Overflow for mechanics?
“That’s a fascinating thought. Why hasn’t it been created yet? In the semiconductor world, up to twenty companies work on new wafer stages every year. They must all have a measurement system. So Zygo, Renishaw and the like start throwing their leaflets at you. They all say: my system can do anything. But when you ask them for reference data, they apologetically tell you they cannot share it because it’s confidential. With a site such as Stack Overflow for interferometers, mirrors or magnetic levitation motors, you’d be rid of the hassle.”
“It would be great to have a kind of review website for constructions, materials and commercially available parts. Suppose you want to build that wafer stage. Then contamination is a very big problem. On a mechanics version of Stack Overflow, you would be able to find material properties, rails and lubricants, including measurement data; everyone would benefit.”
The entire mechanical engineering world would contribute and benefit?
“In the Netherlands, we actually have something like this, because we talk a lot to each other. If you want to know what the outgassing is of a specific cross roller bearing and whether you can use it in a vacuum system, you can hear that in the corridors at the Precision Fair. VDL or ASML employees will inform you. With a little bit of digging, fellow designers from other companies give at least a few hints.”
The Dutch community has sufficient critical mass for this?
“There are very few people per subject. A few dozen at most. They never share business secrets, but they may, of course, share performance data from, for example, adhesives or vacuum pumps. Just measurements, there’s nothing against doing that.”
The people at Mapper always had excellent contact with ASML about such matters?
“ASML is fine with that. A lot is shared at that level in the Netherlands. Not so much in Germany, although it varies per region. You can see it in Erfurt and Dresden. Not in the US. They experience saying what should not be said as very negative. There are repercussions if you do. Why would you say something? It’s not in your job description. In fact, this is very logical. What we do here is illogical. We have a kind of ideal that we all want to move forward. We’re crazy, not them.”
This concludes part 2. Part 1 was published last week. Stay tuned for part 3 next week. Visit the Dutch System Architecting Conference on 20 June to hear Guido de Boer’s full story on how to apply systematicness and regularity when prioritizing R&D in a start-up and in choosing when to outsource or to purchase.