One of the things I review with my student team is the importance of the “Lego approach” to systems. And they still haven't fully gotten this yet, but I said to them, so every time you build a new feature or you build a new product in this suite of products that we've been developing in the Data for Good Center, I said, think about are you adding to the library of reusable pieces? Because if you have some Lego blocks or preassembled Lego blocks, then your ability to assemble new systems goes up and the reliability of those systems goes up. And so taking the extra time to say how can these new features or elements that you're adding to the systems, can you wrap an API around them and grow the library of routines?
And that concept of so I said, so APIs are not just a convenience for others to access your data or access your system. APIs are actually a method of building systems because the originating organization can be the top user of those APIs. And so I said, for example, we have two products. One called Hangul, one called Chetah. One does domain specific search, the other does PDF report analysis.
And they have many things in common. I said, you know, the approach has been you copy code from one to the other. But then you’ve got to maintain the code in two places. If you wrapped an API routine around that and you made it a function, or you made it a subroutine and you added it to the library and you have one copy, so your maintenance costs are lower, but also the reliability is higher. So that insight that I got back from my father about designing Navy airplanes, I've applied to computer systems.[1]
And of course, it requires somewhat of a longer view because if you view systems or applications from the software lifetime perspective, you're more apt to say, how do I make this software more resilient? And how do I drive down the long term maintenance costs of that? And so the Lego approach becomes a design method to build more robust systems. |