Stephen Boyd on the use of theory, in practice

Stephen Boyd, of convex optimization fame, was interviewed by Alberto Padoan in a recent episode of the InControl podcast. What follows is a short segment from their fascinating conversation.

Stephen Boyd:

A lot of people think, "What are the good parts about math, and why should you learn some?" One aesthetic in math is simplicity. Some people make stuff really complicated. There are some stories of a Russian mathematician who spends seven years working on a paper, and someone asks why. He says, "The proof used to be seven pages; now it's three-quarters of a page. Now I'm happy with it." There is this very clean and lean aesthetic in math. And I think it's actually guided me; I'm very attracted to it.

Alberto Padoan:

You think that's the use of theory, in practice?

Stephen Boyd:

I think that's exactly the idea. I see a lot of people who imagine that theory is used in practice like this: "I go grab a theorem from a journal and then apply it." I don't even know what that means; that's completely wrong. I'm not aware of any theorem that's actually used in anything -- maybe some kind of number theory in cryptography. Other than that, I'm not aware of any.

So, in my opinion, the real value of math in applied settings -- control being just one of them -- what it gives you is clarity of thought. And that is extremely important in practice. Here we are in Silicon Valley, and a lot of people build stuff. I could get one team, and say, "Build this thing." And there are a lot of high-level tools now. You can bang something together that looks like it's working. There's a UI, and the app works, and something happens.

But there's another style. Someone thinks about it very deeply, often someone who is trained in math or something abstract, and they don't do anything for a day or two. After a day or two, they look up, and say, "The 87 things that we've been asked to implement are all actually instances of just 3 different things. So we're going to implement that correctly, and then it'll all work together." So then they'll build something.

And here's where this is practically useful. When people just hack something together, to knock off 87 requirements, it's going to be horrible code, badly structured. There's going to be all sorts of weird dependencies. It won't be correct. You'll never be able to actually debug it. You definitely cannot extend it or modify it.

Whereas when you see people who actually think abstractly -- who take time to think about the correct abstractions -- you get beautiful, lean code, that has a high probability of being correct, that is extensible. And this is a purely practical matter: the cost of ownership of that product is a lot less. Number one, it will work. Number two, it's extensible; it's maintainable.