That notion of building with reusable pieces, the box of Lego pieces that I've talked about a few times, that is so fundamental to system design over time, and system building over time. That is a really important skill to gain.
Because what will happen If over time your tool chest grows, and the number of tools you have in it grows. And that new projects that come along, are faster to do because you have so many pieces you can reuse. Right? So that's the objective, that you're never building anything from scratch, you're building by reusing many pieces.
My father told a story once; he designed Navy fighter planes for the US. And he said he never wanted to design a plane that had all new parts. Because it was too risky, especially the new parts not working. But you had to keep too many spare parts on the aircraft carrier and aircraft carriers are limited space.
An engineer never wants to build a totally new plane; want to reuse tried and true parts: less risk and less inventory
11/15/24 Personas meeting:
My father worked for many years for Grumman Aerospace and he was a designer of Navy fighter airplanes. And he said, I remember he said once, you never want to design a plane with all new parts. He said, if you can reuse the landing gear and tires from a previous airplane, you did that. [2]
And the reason you did that was threefold:
- One was you had tested and proven components for the plane.
- The second was you didn't need to keep as many parts on the aircraft carrier for doing repairs.
- The third was it leverages expertise in maintenance crew, who already knows how it works.
So those were three important principles that I learned from the statement that he made that when you're building systems, building it on libraries and prior components, or pieces of other systems you have in your own portfolio, is good engineering. It's building something totally from scratch. You may have to do that sometimes, but we should always pause and ask the question, what pieces can we reuse? Or what's this like that's been done before that we could take advantage of and stand on the shoulders of that prior system because it'll be easier to maintain and in lower cost, for spare parts.
But it's also some tried and true tested pieces.
So one of the things I did when I was building systems for an investment bank, which is where I started my career on Wall street, was I would always ask when doing a new application in the stock market, what, how was I increasing my program library?[1] And if I was growing that library, then over time I would have a set of components that I could draw on and plug together in different ways. And I was then faster at delivering new systems and then the other. And that's sort of an API approach as well, because then if I make an improvement to one of the components, all the systems that use that can take advantage of it.
|