Episode 36: Failure is an Option!

• Links to this episode: Spotify / Apple Podcasts

Unofficial, reviewed transcript. It may still contain mistakes; check the podcast when wording matters.

Speakers are labeled by first name where identified. Unidentified-speaker labels may refer to different people. Bracketed question marks indicate uncertain wording.

Transcript

[00:00:11]  Cameo: Welcome to the Theory of Anything podcast. I am Cameo, and I'm here today with Bruce Nielson and Tracy. You guys want to go ahead and say hi?

[00:00:21]  Bruce: Hey, hey everybody, this is Bruce.

[00:00:23]  Tracy: And this is Tracy. Happy day.

[00:00:26]  Cameo: So today we are talking about the importance of falsification when building software or products. So we wanted to try and take some of these concepts that we've talked about for a long time, Popper's theory of falsification, and see if we could apply those to some of the real world things that are important to me, because this is the industry that I work in, and I know you guys have some familiarity with that. So I want to start today by kind of talking some history about how software used to be built and how we got to where we are today. So back in the day, and I'm going to use Microsoft Office Suite as the reference for this conversation, because I think it's something most people have used for most of their life. It's probably the software that's been more ubiquitous for most of us through many, many, many years. I remember the first time I ever used Microsoft Office or Microsoft Excel when I was in college almost 30 years ago.

[00:01:36]  Cameo: So it's been a part of our modern life for a very, very long time. So back in those days, when a company like Microsoft would sit down to build a piece of software, of course, this software was going to be distributed on a floppy disk originally. And then, of course, that moved to CD-ROMs. But originally, this was going to be something you would go to the store, and it came in a big giant box, even though the disk was just a little floppy, and it came with user manuals and all of this ancillary things that you needed to be able to take this piece of software and install it onto your machine. And as such, they would release the new version every 18 months to 20 months, not just because it would take that long to build all the software, but it also you had all this infrastructure around the release. All the user manuals had to be written, and all the marketing materials had to be created, and the boxes had to be printed, and all of that kind of manufacturing side of software to support a software release.

[00:02:47]  Cameo: And this was how it was for all software for most of the early days of computers. And those of us that are older than 25 remember going and buying software, bringing the software home, taking it out of the box, and installing it.

[00:03:05]  Bruce: There were special stores you could go to to buy software.

[00:03:08]  Unidentified speaker: Yes, there were. Right, those are gone.

[00:03:11]  Bruce: That's a good point, [unclear].

[00:03:15]  Cameo: Software stores existed. But then, of course, things started to change once we had early versions of the Internet. As soon as the Internet got a little more advanced, as we started to move away from modems and the amount of data that could be pushed back and forth over the Internet, of course, one of the first things that ended up happening is software was able to be on the Internet, and we started to be able to interact with software that didn't come in a box. And big applications like Microsoft Office still had big giant development and release cycles, usually on a yearly basis, but now those deployments would come over the Internet instead of being in a box. But then for the companies and organizations that didn't have that big heavy deployment lift, they still had a concept of do a bunch of build and then do a bunch, like a big giant release.

[00:04:28]  Cameo: And it was really typical during those days to have blackout periods when the new software was being deployed. The software is going to be down for 24 hours every month or every three months while we update your software. Behind the scenes for all of that was all of these people who are building this software. And they had come up from a system where they would build software over 18, 19 months, get it all packaged up, hope it wasn't too buggy, honestly. And sometimes for Microsoft that hope did not pan out. Windows, I'm trying to think which of the worst windows we could point to.

[00:05:12]  Bruce: There's some that you don't remember because they were so bad, like Windows 8.

[00:05:16]  Cameo: Yeah, where they release it, it's so bad that everybody in their organization is scrambling to build the replacement just because everybody knows it's just absolutely horrible. And people are skipping that update and people are just... And honestly, Microsoft did all of us a disservice over some of those years where I think they made people really hesitant sometimes to update their software. And then you get into these behaviors where people would skip major releases on their updates, which, by the way, causes just tons of problems. Anyway, enough rambling on that. This interesting side effect that I think is relevant here for us and talking about the importance of falsification is that software was built throughout all this time around the concept of really big bets. There would be people whose job it was to decide what features and functionality was going to be in a piece of software.

[00:06:21]  Cameo: And honestly, they had no real way to validate whether or not those were going to be good features or the ways that they were building them. No way to validate that they were really going to be enjoyable by users.

[00:06:34]  Bruce: Clippy!

[00:06:36]  Cameo: Clippy is such a great example.

[00:06:38]  Unidentified speaker: Oh my gosh.

[00:06:39]  Cameo: Clippy, you know that somebody was really proud of Clippy.

[00:06:44]  Bruce: Yes!

[00:06:45]  Unidentified speaker: Multiple people, right?

[00:06:47]  Cameo: They felt like they had solved this usability problem by giving people Clippy to show them how to use all of the awesome features that were actually already inside of Word. And you know, it's interesting because I took Word and Excel right before Clippy came out as a college course and learned really in-depth functionality on both Word and Excel. And really, Clippy was just there to try and teach people about a lot of these features that had been standard inside of those applications for a while that people just didn't know existed.

[00:07:28]  Bruce: So some people, I mean, like we've got age groups that won't even know what we're talking about when we say Clippy. So we probably ought to describe what Clippy is. That is a good point.

[00:07:38]  Tracy: It's a little bit manic.

[00:07:42]  Cameo: You know, and if we were a visual thing, I think if we had a visual here of Clippy, Clippy exists enough in pop culture that even if people don't necessarily know Clippy's name, they might recognize.

[00:07:58]  Bruce: I agree. Clippy became the laughingstock.

[00:08:01]  Cameo: Clippy became the laughingstock.

[00:08:03]  Bruce: Clippy lives on to this day as a meme of what you don't do.

[00:08:08]  Cameo: But ultimately, Clippy was just a user, like a walkthrough tool. And it was actually almost the precursor to a chat that would help you figure out how to do the things.

[00:08:27]  Bruce: Really, the basic ideas didn't turn out to be bad. Like Clippy, we all make fun of Clippy because of the implementation. But the idea of a wizard that says, let me show you the new features, we still do that today. That became an idea that was improved upon and we still use.

[00:08:45]  Cameo: It did, but man, did people hate it. And I haven't ever really thought about why people hated it so much or why it was so...

[00:08:55]  Bruce: So Clippy was a little animation of a paperclip that when you would run, like, say, Microsoft Word, it would pop up and it would say, oh, I noticed you were trying to do X. Let me teach you how to do that so you don't have to repeat it all the time. And Clippy would try to teach you how to use the interface more effectively. And the first thing everybody did the moment Microsoft came up is they would, like, Google the Internet to try to figure out how to turn off Clippy. Because Clippy was so annoying. Like, you're trying to do something in the middle of your work, and Clippy is, like, not letting you do your work and wants to instead teach you something about the software tool.

[00:09:36]  Tracy: Yes, he had bad timing all the time.

[00:09:41]  Cameo: Well, you know, poor Clippy, because at the end of the day, like, he just wanted to help, right? So one of the things that I love about thinking about this flow of software prior to the Internet is, of course, they couldn't have a way to validate a lot of the ideas or effectively test some of these concepts. And so a lot of software would get built that people weren't using. And in a way, that has never changed, even with the start of the Internet. And now software is, in a lot of ways, much easier to build. But the interesting thing to me and where I think we can really bring falsification in here is people wanted to get more effective at building software, of course. And so during this time, you saw the rise of things like agile methodologies, which were designed to try and make the development of software more effective and more streamlined.

[00:10:52]  Cameo: But none of those methodologies ever really worried about the concept of how are we validating that we should build this thing to begin with? How are we validating that people want Clippy? Even if we can see from usage statistics that people are not utilizing 50% of these awesome features that we know would make their life easier, there's a huge assumption that they want their life to be easier. We just decide that that's something that they want, and then we build software to answer this problem that we believe they have, kind of like a god, like, okay, we're here to fix your problems. We're going to give you Clippy to do it.

[00:11:41]  Bruce: It's also interesting to note that there was an attempt for a while to build stripped down versions of these software, not like by Microsoft, but like other companies trying to compete with Microsoft, which is back then was a really bad idea. They would build like a word processor that only had the basic functionality you needed in a word processor, and they didn't have all the bloat of extra feature. That's what they called it, the bloat of extra features. So it would be theoretically a cheaper piece of software, but might be just as effective because of the 80-20 rule. The problem was, is that it's true that people only use 20% of the features, but everybody uses a different 20% of the features.

[00:12:20]  Cameo: Yeah, that's actually a great point. And ultimately, the real problem at the end of the day is, is that a group of people building software or a company building software was still really more focused on output than outcomes. That the idea was, how do we get all of these features into the software versus outcomes of how do we support varying kinds of users in the place they need to be and really solve their problems? There's actually a great quote from a software guy that's a bit of a hero of mine, his name is Jeff Patton. He's a local guy here. And he says, when we're building software, we kind of get the idea that our job is to fulfill these requirements or to deliver these feature sets. But really, our job when we're building software is to change the world. And he says, yes, that sounds a little bit flippant and a little bit grandiose.

[00:13:26]  Cameo: But at the end of the day, we're responsible to pay attention to the way the world is now and look to see if there are problems that we could solve to honestly make the world a better place. And some of the problems are big and life-changing, and some of them are really small and might seem inconsequential and still can have really huge impact. And I'm going to share just a small story as an example of this that I think maybe can resonate with a lot of people. I have a friend who posted on Facebook a picture of a spatula. She had broken the handle off of her spatula. And she said, I feel like this is the most privileged thing I could ever complain about, but I'm heartbroken that I broke this spatula. She said, I cook with a spatula every single day for like 15 years, and I buy lots of other spatulas, because I know this one's getting older, and I keep thinking, I'll replace my spatula.

[00:14:29]  Cameo: But it fits perfectly in my hand, and it's got this really sharp place right at the beginning that picks up a pancake just perfectly without bending it underneath, or those spatulas can't get under the pancake. She's like, this is the perfect spatula, and I've never found its like, and I've looked and looked and looked, and now it's broken. And I thought, how funny that it's 2021, and we don't even know how to build a spatula. Right.

[00:14:59]  Bruce: Our spatula technology has not improved.

[00:15:02]  Cameo: Well, and maybe it's gone backwards because somebody got excited about silicon, and what an awesome surface it is to not stick. But the only way to make it rigid enough to flip anything is to make it thick. And so the person who got enamored with how this silicon thing could make a new spatula didn't actually know what somebody might want a spatula to do. I think this really interesting challenge of the modern world is if we're building things, how do we even know what problem we're solving for somebody? And then how do we know that we're solving it in a way that helps them? You know, because something like a spatula, if you said, like, what problem does a spatula need to solve for somebody? They're like, it flips things, right? And some of the things that might be important is I don't want it to stick to my food. And maybe you don't think about, like, how important the handle needs to feel.

[00:16:09]  Cameo: You know, she even said, I have these little teeny hands, and all these spatulas have these big, round things, and they feel uncomfortable in my hand.

[00:16:21]  Bruce: Have you heard of the book The Design of Everyday Things? Don Norman's book The Design of Everyday Things?

[00:16:25]  Cameo: Yes, yes.

[00:16:27]  Bruce: That's what he talks about in his book, is the way we often end up trying to design things to look cool instead of just be useful.

[00:16:36]  Cameo: Well, and I would say, Bruce, that the interesting challenge is I don't always think we understand what makes things useful. So, that was software back in the day. Agile came in and Agile said, hey, we need a couple of things we need to be doing here. We need to be building software in smaller increments. And Agile, as a methodology, and I don't even want to call it just a framework, but almost as a conceptual thing, knew there was value in building smaller batches and in building incrementally. It had some notion of the concept of a build-learn cycle. But I would say over the last many years, as most companies try to use Agile in real life, that the idea of the incremental and building in smaller batches as a learning mechanism isn't talked about as much as a lot of the other side effects of Agile. I would say that that is not the primary reason that companies use or...

[00:17:58]  Cameo: I mean, I don't know, Bruce, do you hear that talked about in the circles that you're in in building software? Here's the benefit of Agile.

[00:18:06]  Bruce: So, we should do a whole episode on just Agile development because it ties so deeply into Theory of Knowledge. But it is so easy for Agile to very quickly become just something you do because everybody else is doing it. And with no real rhyme or reason as to why it matters. And the moment you do that, you end up with kind of a worst of both worlds type situation where you now lack the benefits of the old traditional style, which did have benefits. I think people often miss that fact, you know, mixed with none of the benefits of the new style. No, go, keep going.

[00:18:54]  Cameo: I'm sorry.

[00:18:55]  Bruce: Well, it's, and I think it's a tough thing. Like I, my boss at work, this is not my current job, but previous job. He brought in some Agile experts to teach us Agile. And I was in a meeting, he himself didn't really seem to understand it that well.

[00:19:14]  Cameo: Sure.

[00:19:14]  Bruce: And which is pretty common at a CIO level. They kind of know it's a buzzword. I need to make sure I'm doing it, but they don't really necessarily get it. And in a meeting, he started talking about how he wanted to make sure everybody's cadences were on the same date, because that would be convenient, and they needed to use the same point system. And the consultant who had been brought in to teach Agile goes, why is it that you like Agile? Do you like Agile because you like estimating things in points, or do you like Agile because you like the fact that it actually produces better software? And this is exactly the right point that he immediately starts making fun of her, you know, in a fun way, but he wasn't getting it, right? He really just wasn't getting it. To him, Agile was just this methodology he had to make sure people were doing because that's what good CIOs did.

[00:20:10]  Bruce: To the consultant, Agile had no purpose unless you were using it to try to get a fast feedback mechanism on your software. And there was no other purpose to it. And insofar as points or whatever in the methodology wasn't useful to that purpose, you should do away with it, right? Just do it only if it's going to work. And the consultant had exactly the right attitude. And that was one of the best implementations of Agile I had ever seen. In fact, you and I were, when that first happened, you and I were still working together. So I was a consultant. So I would have my customer who treated me like an employee, and then I was working with Cameo at the actual company I worked for. And I came back and I said, I've actually seen one of the best Agile implementations I've ever seen at this company. It didn't last, though. It started to fall apart within a few months.

[00:21:04]  Bruce: When the consultants left, when there was pressures from above, it became increasingly hard to hold the Agile implementation together, because nobody really cared about it. There weren't rewards built around it, so people would immediately start falling back to a more traditional mindset. And yet they kept all of the imagery of Agile. They still talk… [overlapping speech unclear]

[00:21:29]  Cameo: Right, the ceremonies and the way of talking.

[00:21:33]  Bruce: Yes. So they still talk as if they were Agile. They still acted like they were Agile. They were going through the Agile motions, but the actual Agileness was gone.

[00:21:45]  Cameo: Which I think is the most common implementation of Agile right now.

[00:21:49]  Bruce: I agree.

[00:21:50]  Cameo: The methods. And I think because most organizations, either, like you say, buy Agile for the buzzwords, or, you know, I work for a big Agile consultancy now, so I'm pretty deep in this world. Most of the customers that I see, they buy Agile for predictability. What they want is a predictable cadence of delivery. And Agile can give that to them. You know, a high-performing Agile team, you have things like Velocity, where you can say, we're pretty routinely going to build XYZ in X amount of time, right? And executives love that because knowing how predictable your system of delivery is really feels awesome because you can say, hey, we're going to request XYZ of our IT department, and they're going to give it to us in three months. And we can estimate these things and get it out the door.

[00:22:57]  Bruce: By the way, how predictable have you found Agile to be?

[00:23:01]  Cameo: I believe that if you've implemented it fairly with a lot of controls, it can be quite predictable.

[00:23:10]  Bruce: I think it's fairly predictable in terms of its output. I don't think it does as well in actually predicting when your project is going to be done.

[00:23:18]  Cameo: Well, done is an interesting word, because most companies view done as the place where we got to that matches our assumption from when we started.

[00:23:34]  Bruce: Right. I don't even know if Agile— it may do a better job than traditional. Traditional used to have these spirals out of control that Agile just doesn't seem to get into anywhere near as often. And those spirals out of control created mass unpredictability for a number of reasons. So maybe Agile does help solve that problem and thus creates greater predictability. But the honest truth is, as an Agile project manager, there's no such thing, but as an Agile project manager, the main thing I did was I didn't try to match the schedule, but I did understand how to use Agile's ceremonies and everything to get the customer to come along and them to make changes to the schedule. I don't know that I was necessarily more predictable if you're looking at it on a project level. I think what it did, though, is it created this level of communication that allowed the customer to become comfortable with the fact that some things had to change now and again.

[00:24:36]  Bruce: And they felt like they were making the decisions instead of me, which made a big difference emotionally. I think Agile has a number of things that does well like that.

[00:24:44]  Cameo: No, that's actually a great point. They are front row participants and deciders of their own predictability. They have the ability to choose to be predictable, the end person who's kind of making those choices, which you could put under the umbrella of the business. But predictability at the end of the day is a pretty useless metric. I mean, it's desirable if you don't have it, like if you don't have a trustworthy system of delivery. But output isn't what makes an organization money. And ultimately, a company only earns or saves money when the software they built is used by users and when users like it and enjoy it.

[00:25:36]  Bruce: And when it solves a problem. And when it solves a problem.

[00:25:42]  Cameo: There is definitely this focus on problem-solving within software. I think for non-software people, sometimes that's a funny way to describe it, because a lot of the way people use software in their day-to-day isn't necessarily about solving. When I sit down to play a video game on the Switch with my kid, neither of us think about the fact that we're sitting down to solve a problem. Right. That's not what we're doing. We're sitting down to have fun with each other and play. And a fair amount of software, especially in the consumer space, falls under that umbrella that the end user doesn't think about what they're doing as, quote unquote, solving a problem. Yeah.

[00:26:37]  Bruce: Just as a side note on that, though, the whole concept of gamification is the realization that game interfaces are very specifically about solving made up problems because it's fun to solve problems. And so they're trying to figure out ways to apply that to real world settings. Well, and it's fun to compete. Yes. Yes.

[00:26:59]  Cameo: Because I think that's also a big part of what the appeal of gamification is, is that people like to compete with each other and get awards.

[00:27:10]  Bruce: Yes.

[00:27:12]  Cameo: Also, you know, that whenever I see, so you pretty regularly see people like talking about kids today, they need, you know, trophies for everything, participation trophies. And I always think about gamification, because gamification has taught us that everybody likes a participation for a trophy. [wording unclear]

[00:27:32]  Bruce: Yes.

[00:27:36]  Cameo: Even though we just want to disparage the kids and say, you know, it's all their fault for wanting to get rewarded for doing almost nothing. So over the last, I would say, well, something happened over the last several years. And a gentleman named Eric Ries released a book that was called Lean Startups. And he did a bunch of things really wrong that will give us pain for many years, one of them being how he used the word MVP. But ultimately, what he did right for software, and what I think is going to be game changing for products in general over the long term, is he said, hey, our job is not to build software. Our job isn't even to, when we build software, we shouldn't even be saying, oh, I'm coming in to solve a problem. Our job is to build a test to validate our assumptions. And every piece of technology we build should always be, with that being the first thing that we do, an experiment that's designed to either fail or succeed, but ultimately it's designed to teach us how to solve a particular problem, or in some cases, to validate that it's even a problem worth solving.

[00:29:04]  Cameo: And this is where I think that software is going to lean very Popperian, because as we know from being on this podcast, Karl Popper, his falsification principle, suggests that for a theory to be considered scientific, it must be able to be tested and conceivably proven false, or true. And I think that the same ends up being true for any concept that anyone wants to build, whether it be a service or a product. Our first job is to figure out how something can be tested, and can our assumptions be proven false or correct? And so here's where I think that things start to get very interesting for people working in technology, because seeing your job as our responsibility is to create a series of tests is a totally different job than our responsibility is to create a bunch of features that we're going to sell to people. Yeah. And it's interesting because on LinkedIn, I've been posting kind of fairly regularly about the concept of failure.

[00:30:37]  Cameo: And, you know, businesses are traditionally super failure adverse. And so even before you include Agile or software, you know, business leaders, their job is to not fail, right? That's ultimately what people, oh, you know, they go and get MBAs so that they can come up with better concepts so that they are less likely to fail. But then those same people will come and they'll sit down in the conference room and they will come up with a bunch of assumptions that they're going to fund in the form of big initiatives or, you know, whether they be marketing initiatives. There's still every single one of them based on a set of assumptions that a person has that might be educated assumptions, but they are still just assumptions. And then they fund them and then they go and deliver on them. And then, you know, if somebody's a failure, if their assumption is incorrect, then we fire them and we move on to the next person.

[00:31:49]  Bruce: To put this in perspective with epistemology, a business initiative could be thought of as a theory, right? It's a theory for you've got some theory. If we build this functionality, then it's going to increase our sales by this much because of this reason or something along those lines, right? And then actually going and implementing it, you're actually trying the theory out and exposing it to…

[00:32:17]  Cameo: Do you think if you were to go into the boardrooms across the world and describe what they're doing that way, do you think that these business leaders sitting in boardrooms, do you think that they would agree with you that that's what they were doing?

[00:32:32]  Bruce: No. And if they did, I still wouldn't believe they actually believed it, right? It's even ones that say, well, we want to fail with... I had a boss who used to say we want to fail with flair, right? He wouldn't let you fail on anything, right? I mean, like he would just get so angry for every little perceived problem, right? I don't think that's the way we're wired. And I think there's even kind of a rationality to it. And maybe there's even a little bit of truth to it. Even false ideas usually have some truth to them, right? And the idea might be something like this, if I try to put it in its strongest form. We're hiring you, Mr. VP, because you have experience in this field, and so it's up to you to have the right theory as to what's going to actually make us money, and your theory failed, therefore you failed, and so we're going to fire you.

[00:33:23]  Bruce: And maybe I'll even give a little bit of credit to that way of thinking. But let's be honest, the real truth is that you're never solving the same problem twice, right? It's just because someone has experience with some seemingly analogous problem in one area doesn't mean that they therefore know how to solve the same problem in a, we call it the same problem, but a similar sounding problem in a different area. You're always actually trying to be creative. You're actually always trying to come up with some sort of completely new solution to a completely new problem unique to your business that has never been solved before in the history of the world. If it is a problem that is actually solvable by known knowledge, you probably don't even perceive it as a problem. You probably just go buy the piece of software you need to take care of it, and you're done.

[00:34:17]  Cameo: Right. Well, and it's interesting because one of the things that gets talked about a lot in product management, when polio was running rampant and the iron lung was the way that you treated polio, yeah, you can go in and keep figuring out how to make a better, more efficient iron lung. But ultimately, what you really need to be doing is figuring out how to cure polio or immunize against a disease that forces people into a situation where they need an iron lung. You know, if I'm a manufacturer of iron lungs, I probably don't have the expertise to even start to envision how to build something to immunize people with polio. But it is interesting to kind of try and get that perspective of what is the right set of problems to actually be trying to solve. And you're right about people are hired for their expertise, and their expertise is supposed to ensure that these bets that the company is making are successful, right?

[00:35:38]  Bruce: Yeah.

[00:35:39]  Cameo: So my big thing now, though, is...

[00:35:42]  Bruce: By the way, let me just make a comment here. It's interesting that we kind of talked about this in the interviews with Bart, where he was talking about how he tried to come up with a consultant company that utilized Popper's epistemology to encourage companies towards knowledge creation. But there's this idea, you have to conceptualize your company correctly. And that's not even necessarily an easy thing to do. So let's say you conceptualize your company as Polaroid, as we create Polaroid cameras. If that is your expertise and that's the problem you're solving, you are literally just out of business the moment the digital camera and phones come into being, right? Because your problem just dried up entirely, right? If instead you conceptualize yourself as, we're a company that's experts in photography, then you have a more generalized problem you're trying to solve and you're trying to figure out how to keep advancing that problem, which goes well beyond the need for Polaroid film.

[00:36:51]  Bruce: And a lot of companies that disappear, it's because their problem disappeared, and they never really reconceptualized theirself in such a way that they were still providing something valuable to the market.

[00:37:04]  Cameo: Well, and I would suggest that's because their boardroom was filled with people who didn't see their job as to come up with concepts, test those concepts and then use those within the market. Their job is to bring the expertise from their past experience and to make predictable bets based on the past experience. So and this is where I think we're at this really cool let's take risks and make mistakes kind of turning point within the professional world. And software and technology, I think, is leading this, you know, as definitely the tip of the spear because if you don't have a physical product, the idea of creating a set of tests is a whole lot easier than if you have a manufacturing cycle or if you have, you know, and so I can come up with concepts all day of software I want to build and come up with cool ways that I could test those concepts, prototype them without ever needing to build software, you know, there's lots and lots of ways to do that.

[00:38:19]  Cameo: But I think it gets more difficult if you do have an actual physical product that you're trying to build. But only just barely, you know, the emergence of things like 3D printing allow us to come up with concepts and have them in a physical form sometimes within hours.

[00:38:39]  Bruce: Very cool.

[00:38:40]  Cameo: But ultimately, the key to all of this is to change our mindset within the business world from being confident that we have the right expertise to solve this problem to assuming we don't have the answers at all for how to solve the problem and that our job is to come up with small failures, small tests that we can use to validate those assumptions way before we expend energy or effort on trying to manufacture or produce our solutions.

[00:39:21]  Bruce: That makes sense. And that would be how you apply the concept of creativity to a business, right? Obviously, all businesses have to be creative in some sense, but you're expanding that notion well beyond the guardrails that usually exist of trying to take a specific business that you already have running and maybe make it a bit more efficient or something along those lines. How do we actually provide whatever value we need to within our space to the market?

[00:39:51]  Cameo: So can I extrapolate an assumption out of what you just said, which is, is failure required for creativity?

[00:40:03]  Bruce: So I think, yes, that would be my answer. I think you could make up some scenario where you just get lucky every single time, and, you know, your first conjecture happens to be right. But I think even in a case like that, that would be a misunderstanding, because the real truth is, is that the conjecture process has many levels to it. And so you probably came up with an initial— even if you got lucky, and your first conjecture was exactly— it was the Walkman, you know, it was exactly what everybody really needed but didn't realize they needed. You actually probably went through a series of conjectures at some other stage where you had to kill initial bad conjectures. So my guess is that creativity always requires the death of ideas, and therefore, in some sense, failures.

[00:41:00]  Cameo: I think I'm in love with the statement that you just said. Creativity always requires the death of ideas. So, you know, when we were talking about AlphaGo last week, was that last week?

[00:41:16]  Bruce: That was last week, yeah, or two weeks ago.

[00:41:18]  Cameo: Two weeks ago, when we were talking about AlphaGo, you were mentioning kind of these intuitive leaps that AlphaGo was making. Do you think that AlphaGo, I mean, so much of what AlphaGo was doing is non-visible, just watching, you know, maybe even to the programmers, these calculations within its program. Was it making lots of these kind of creative failures and learning from those?

[00:41:47]  Bruce: It does. Yeah. So think about the episode where we talked about how reinforcement learning actually works. And that was why I did that episode first before we talked about AlphaGo. And remember, maybe you won't remember this, but there's something called the Explore-Exploit trade-off. OK, that was one of the things that came up in the podcast episode. That is the key to how reinforcement learning works. Reinforcement learning explores failed approaches as a way of trying to find ones that work better than its current policy. And there's a whole science to it, right? I mean, there's tons we could go into. We so barely scratched the surface with reinforcement learning. But if you just always follow your best policy, then you get stuck in a rut and you can't improve. But if you always just explore, then you're not utilizing the knowledge that you gained.

[00:42:43]  Bruce: So you have to have this careful tradeoff between explore, exploit. And basically what you do is you turn it down over time. So you start with initially a heavy explorer, basically making random moves in a grid world. That's the way it would work. It would depend on the problem you're trying to solve. And then later on, you start turning down how often you take random moves, and you start favoring instead following your best policy. But you never actually, at least during the training phase, you never actually get rid of the explore, exploit tradeoff. And the reason why you don't is because it's known that you can only arrive... The theoretical mathematical guarantees of arriving at an optimal policy only exist at infinity so long as you're always doing some exploration.

[00:43:33]  Cameo: That's fascinating if you look at it applied to the business world, because I think you could say the same set of rules are critical for a company. You know, because companies have... There's a cycle you can follow for businesses where they start out... They tend to be creative when they're initially starting out on varieties of different ways that they want to try and solve a problem. And then as the organization becomes more and more mature, it solidifies processes around all of those things and becomes less tolerant to exploration as a rule, because it knows how to leverage that maturity predictably to guarantee some sort of return. But you stop having that creativity and risk taking kind of test as part of your key makeup, and then the organization stops being competitive within the market, and ultimately it dies off. In fact, that's why we're seeing it used to be that a company could be successful over 12 or 15 years.

[00:44:51]  Cameo: And now they're seeing that the length of time that an organization kind of can grow and then contract is shortening. And I think it's because of that, because the cycle of innovation across the world is getting faster. But that inclination of humans to shy away from creativity, the more stable we get, is kind of just baked into who we are.

[00:45:23]  Bruce: You might even say that, you know, reinforcement learning is not the same as animal reinforcement learning. Those two are very different things. But obviously, the computer one was inspired by the animal one, insofar as some computer scientists thought he understood animal reinforcement learning, but in fact didn't really. But there is some overlap there. And what you're kind of saying is, is that, you know, humans are still animals. We still have kind of an incentive structure that, you know, pain, pleasure, things like that, that apply to us. And we have kind of our own explore exploit trade-off that we do. If we looked purely at animals, everything's harder with humans because in theory, we can change our own ideas, right? This is the universal explainership, the fact that ultimately ideas went out [wording unclear], that inborn ideas are never permanent.

[00:46:19]  Bruce: But particularly with animals where that's not true, you can really see this idea of curiosity. And we know it also applies to humans. Where curiosity is something that's important to the survival of animals. We're going to do Animal Intelligence is one of our podcasts. And there's a reason why animals and even humans have this natural curiosity. It's because there's survival value in doing exploration, right? But then they have— they can't just be curious, because that's not a good survival strategy. They have to mix it with fear. They have to mix it with this impulse to pull back from the curiosity and have conditions under which they are curious and conditions under which they're not curious and that they're just too fearful. And so I think you're right. There's going to definitely be a natural built-in for humans propensity towards both fear and curiosity that are in conflict with each other at times.

[00:47:17]  Bruce: And I think you see that in businesses, right? You know, if you've captured some market, your first impulse is to try to defend exactly what you're currently doing, because it's been working, you know, up to this point.

[00:47:28]  Cameo: Yeah, so that kind of that's, I don't know how heavily I brought Popper into this conversation. I remember when we had Bart on, and you guys were talking about like, why do more companies not use philosophy within their business models? And I think I had said something at the time, like nobody's looking at philosophy when they're building their business.

[00:47:53]  Bruce: Do you know, I'm going to agree with you on that. And let me go a step further. It just, Karl Popper described what actually was already happening with science, right? And he didn't even initially realize it could be generalized to other areas. His interest was in science. And Donald Campbell was the one who started talking about evolutionary epistemology, and Popper endorsed his ideas, as we've talked about, where he was really trying to figure out, hey, wait a minute, these ideas apply all over the place. They're like ubiquitously all over the place, knowledge creation is going on, and it's important to understand how it actually works. But the simple truth is this. You don't actually have to know the philosophy to be able to do error correction. Philosophy doesn't have to have anything to do with it. Scientists are really good. The scientific community, let me actually clarify, scientists personally aren't very good at error correction.

[00:48:56]  Bruce: The scientific community is awesome at it. In fact, there's a book, John Rauch, The Constitution of Knowledge, that I just finished reading. We should actually invite him on the show sometime. Where he has worked out, so Popper understood the importance of institutions, but he didn't really explore it very deeply. So John Rauch is trying to explore how do institutions affect our ability to create networks that produce truth versus networks that produce error.

[00:49:27]  Cameo: Oh, fascinating.

[00:49:29]  Bruce: And he calls that the Constitution of Knowledge. It's an analogy with the US Constitution, or for that matter, the British Constitution, which isn't written down. What are the traditions? What are the ways of doing things? What are the organizations that exist that allow a network to be more likely to pass truth than error? And then he gives the example of Twitter or Facebook versus the scientific community. Twitter and Facebook, at least the way they're currently set up, by far and away, they favor falsehoods over truth, right? Wikipedia, that's not true. Wikipedia absolutely favors truth over falsehoods, the way it's currently set up, because it's far more similar to the scientific community, which is this tradition that we've built up that we know really does favor truth. And he explains how the nodes in the network, there's no central organization, but the nodes just don't do a good job of passing along falsehoods.

[00:50:26]  Bruce: There's things that exist that just make it so that they tend to lose interest in false theories, and the false theories tend to die out. Whereas with Twitter and Facebook, the false theories tend to spread better than the true theories because they're attention-grabbing and things like that. Basically, what he says is this idea of the free marketplace of ideas, he says, by itself, that would never work. You actually have to have certain institutions in place to favor truth. And if you don't have that or if you let those get destroyed, then you're not going to be favoring truth anymore. And in many ways, I think that's what we're talking about with business as well, right? It's not just a free for all. You never want just a free for all because that really doesn't favor the truth. And then Popper wasn't so much saying science should be done this way.

[00:51:22]  Bruce: He was trying to understand why science was effective. And then he was trying to describe that. Once you've described that, then that becomes really useful. Then you can say, well, how would I apply that to a business setting? But you don't have to. Feynman famously said that scientists need to understand the philosophy of science, like birds need to understand the theory of flight. You don't really have to understand it to be able to do it well. You just have to be part of the organization that has the right institutions. And a lot of those institutions grew up by chance. They're the ones that happened to work. It's evolutionary. That's the way this works. And because of that, you really don't have to bring Popper in to be effective. But it might make you more effective if you actually understood what was going on, if you actually had a good theory for how does knowledge get created, and then tried to figure out how to apply that.

[00:52:17]  Bruce: That might make you more effective. But there are other best practices out there. Radical Candor we talked about, Agile we've talked about, which weren't really inspired by Popper's philosophy. Maybe a little bit, like in the case of Agile, some of the Agilists were inspired by Popper, but a lot of them were also inspired by Kuhn. So I mean, like, it just sort of depends.

[00:52:39]  Cameo: But it's interesting when you bring science into it, because Popper or not, core to the concept of science is the idea of making a hypothesis and testing the hypothesis.

[00:52:54]  Bruce: Yeah.

[00:52:55]  Cameo: That is a missing concept from business.

[00:52:57]  Bruce: Yes. And you could get that.

[00:53:00]  Unidentified speaker: Completely absent. [overlapping speech unclear]

[00:53:00]  Bruce: Even if you don't know Popper, you could look at the scientific community, you could say, what are they doing right that we're not doing? And you could come to the exact same conclusions as if you tried to take Popper's epistemology and apply it to business. Right? Because it's the same thing. You're looking at what actually works in real life to find the scientific theories that are the ones that have the highest verisimilitude, the ones that are the truest. How do you go about doing that? It's really the same thing. There's only one way to do that. Right?

[00:53:34]  Unidentified speaker: There's only one way to do that.

[00:53:36]  Bruce: There's only one way to do that. You're either going to follow the scientific method, which Popper says doesn't exist, but I'm going to use it in a very general sense. You're either going to use that in business, and your business is going to grow knowledge, or you're not, and your business isn't going to.

[00:53:51]  Cameo: So I will tell you, though, and I'm only basing this off of kind of my experiences on LinkedIn, where I have a large enough following that it's an interesting sample size, but I'll tell you, nothing will get people riled up, like me suggesting applying the scientific method, quote unquote, to business.

[00:54:16]  Bruce: Yeah.

[00:54:17]  Cameo: Like people will come out and say, oh, good luck with that. You'll drive companies into the ground.

[00:54:22]  Bruce: I've seen people say that to you. Yeah.

[00:54:24]  Cameo: Passionately that this, like I am speaking radical concepts to suggest, to apply what works for science to business.

[00:54:36]  Bruce: Right.

[00:54:37]  Cameo: It's really shocking to me that it seems so foreign to people when we can see that concept and that approach working so successfully to create scientific knowledge.

[00:54:52]  Bruce: Yeah. You know, let me just go out on a limb here. If you were to go to the average scientist and ask them, why does science work? I don't think you would get a good answer from the vast majority of scientists.

[00:55:06]  Cameo: Interesting.

[00:55:07]  Bruce: I think a lot of it is professionalism. They get trained to do things in a certain way, and they don't truly understand why in a lot of cases, right? Because a lot of it just grew up as traditions. Nobody implemented it for a specific reason, or if they did, the reason didn't necessarily come with the tradition. And this is the way traditions work, right? I think when I've seen scientists talk about a scientific worldview, they consistently, I mean, the ones, I just can't even think of exceptions. They consistently explain it wrong, right? And in really bad ways. One of the ones that I used to put on Facebook that I've given up on, is they would like put, here is the mindset of a scientist. You know what? I don't care about the mindset of the scientist. It has so little to do with the progress of science. And it's, you know, they have to be rational, they have to be looking for, you know, what's wrong with their ideas.

[00:56:06]  Bruce: And there's nothing particularly wrong with any of these things. But one individual scientist is never going to get there. What really matters is that they're part of a culture where they have to subject it to other people who think differently, right? Then they have no choice. Even if they're completely ideological, they're going to have zero choice but to buttress up their arguments against who they're going to encounter, to figure out how to make experiments that anyone else can intersubjectively do. They will naturally move the right way, not because they have the right mindset. It doesn't matter if they have the right mindset that much at all, okay? But because they're part of this community and they know they've got no choice. They're going to be a laughingstock if they don't, right? And that kind of shows just how important the institutions are and how they really matter more than the individual mindset.

[00:56:59]  Bruce: One could argue individual mindset still matters, and I think you can make a good case for that. But even Popper talked about the importance of the dogmatic mind, right? He kind of started off thinking that that was a bad thing and then changed his mind over time. That a lot of cases, the reason why science works is precisely because individual scientists are dogmatic and they won't give up on theories easily. So they therefore force that community to deal with the strongest possible defenses and criticisms of a theory that's false until it's been fully dealt with. Because you don't know up front which theories are true and which ones are false, you have to, the community needs dogmatic individuals who won't give up on ideas easily. Or the community won't be considering some fairly good ideas long enough or well enough that they actually develop into good ideas.

[00:57:54]  Cameo: That's interesting.

[00:57:56]  Bruce: Just to use this as an example, general relativity from Einstein. General relativity, like this is literally one of the two greatest scientific discoveries of all time, the other one being quantum physics, right? He did not win a Nobel Prize for general relativity. They did give him a Nobel Prize. They couldn't deny that he was producing some really interesting stuff, so they gave him one for the photoelectric effect. But like Einstein won a Nobel Prize for the photoelectric effect, not for general relativity. Think about that for a second.

[00:58:34]  Cameo: Right.

[00:58:35]  Bruce: And the reason why is because his ideas were considered controversial. Right.

[00:58:39]  Cameo: They were considered maybe wrong, not just controversial, right? You can't give somebody a Nobel Prize if they screwed up, right?

[00:58:50]  Bruce: But maybe you should. You know what? Maybe we should. Okay. That may not be the way we currently think of the Nobel Prize, and that's the problem. But if your idea [is] that failure is good, maybe we should have given Einstein a Nobel Prize for a theory that we thought might be wrong. That would maybe make some sense if it solves some really interesting problems. But that's just not the way the Nobel Prize is ever actually going to probably be used, just because human beings aren't like that, right? No, no, no.

[00:59:23]  Cameo: We want to reward the changing of the world that ultimately did… I mean, even looking at it in retrospect, the reason why it seems laughable that he wasn't awarded the Nobel Prize for the theory of relativity was because we've all decided it's right now, right?

[00:59:40]  Bruce: That's right.

[00:59:42]  Cameo: And although, you know, maybe not also.

[00:59:44]  Bruce: So, yeah, it's actually wrong. But it's right.

[00:59:51]  Cameo: Well, and what I love is at the end of the day, like even the concept of, quote, right and wrong, when it comes to ideas, is it's always emerging and growing, you know? And what 10 years ago or 20 years ago made us say, oh, wow, Einstein was right. Wow, he was right. And now we're like, oh, well, he had some really great ideas.

[01:00:17]  Bruce: Right. He had a theory that had heavier verisimilitude than its competitor, which was Newton's theory, right? There's— no one really doubts that today that Einstein's general theory of relativity is superior to Newton's in every way. There simply are no exceptions that we know of, right? And because of that, it's now one of the two great paradigms of physics. And there's even... I don't... And I'm not trying to make fun of science. Part of the institution of science is a certain amount of orthodoxy and intolerance to new ideas. That's what you would want in science to some degree. What really happened was is that his theory continued to get corroborated. They continued to find test cases that required an understanding of general relativity. And lo and behold, you go do the test, and he's right each time. As those tests... And this does come from Popper.

[01:01:18]  Bruce: A lot of Popperians think there's no such thing as a positive argument in Popper. There is. It's called corroboration. And to Popper, what that is, is that you have a potential chance to falsify through an experiment, and it fails to falsify. So each time they come up with this new idea, well, according to relativity, this is what should happen. Let's go try that. And each time it works, you know, GPSs require an understanding of general relativity. You literally can't make a GPS without an understanding of general relativity. Once you've gone, you try these things, and they end up... Yep, turns out you need to understand general relativity. That does corroborate the theory. Those are the positive arguments for the theory. People might argue with me here, but they're also negative arguments for the previous theory. Yeah, okay, true. It's not super clear-cut because you're always comparing theories.

[01:02:14]  Bruce: So positive argument for one theory is always negative argument for another theory. The reverse is not as true, but any positive argument is also a negative argument. That's why Popper emphasized negative arguments. So that's what happened, though, is we corroborated the theory more and more over time until it just really, there was no other theory out there that was truly its competitor anymore. And people just gave up on trying to figure out how to adapt Newton to accomplish the same things, or whatever. The true competitor to general relativity today is quantum gravity, which does not exist as a theory. That's why it can't be a competitor yet.

[01:02:55]  Cameo: All right, well, those are some of the thoughts that I wanted to explore today. I love where the conversation's taken us. All right, well, I would say that we could wrap up this conversation. I think it's been a fascinating one. I like the kind of settling on the dogmatism that is in science, because I think in spite of the fact that I'm here heavily advocating that companies need to be more risk… I don't think it... Here's maybe my finishing thought. I don't think it's risky to be failure and mistake advocates within an organization. Ultimately, I think organizations that have a tolerance, not just at the executive level for taking risks, but push the ability to do experimentation down to their teams, and that can create a culture of experimentation as a way to develop speed, so that your ultimate goal, at least early in any product conceptualization, is to figure out how quickly you can invalidate that idea and be really Popperian with it, and then get those ideas out of your way, so that you don't expend time and money focusing on things that are non-valuable.

[01:04:36]  Bruce: Yeah, and we mentioned this when we were doing the Bart interviews, but you're either going to do this as part of your company culture, or the knowledge creation will happen by the death of your company and the success of other companies that have a better idea. And that is the value of the capitalistic system. It creates knowledge at multiple levels, and it incentivizes creation of knowledge, creativity. But even if no one individual company is good at agilely changing its ideas and experimenting, across the market, those ideas will exist, and we will see progress. This is a little like the analogy with you don't need any one individual scientist to be non-dogmatic. You just need the system to be non-dogmatic. That's true of capitalism too. But once you know that's true, do you really want to be the dogmatic business that goes out of business, right?

[01:05:32]  Cameo: Right. Do you want to be a Blockbuster who couldn't visualize how to be a different, you know, their main money maker was late fees. You can't give people, you know, movies in the mail with no clear return deadline if the way you make money is by late fees.

[01:05:49]  Bruce: Yeah. Interesting. I didn't know that.

[01:05:51]  Cameo: Well, that's my interpretation.

[01:05:56]  Bruce: I think that's a decent interpretation. I never thought of that.

[01:05:59]  Cameo: Well, and I have Blockbuster bitterness. I remember this would have been like early 90s. I had a movie, you know, that I just forgot to take back. And I remember standing in a Blockbuster, and they wanted $87, and it had been like two weeks. You know, and that would be a lot of money for a late movie now, even though we don't have that concept anymore. But back then, like, that was probably close to $300 in today's money. And I swore I would never go into a Blockbuster again. And I never did.

[01:06:36]  Bruce: Do you use Redbox?

[01:06:39]  Cameo: I did use Redbox for a while. And you know, Redbox, if you don't return your movie, after I think it's 30 days of a dollar a day, you've bought the movie, and they no longer charge you late fees.

[01:06:52]  Bruce: Interesting. So that's a better... That way they can't just make the money off of you, just continue to make the money off of you, renting it to you.

[01:06:59]  Cameo: Yeah, which was, I truly believe, core to Blockbuster’s business model was the levying of those late fees for a substantial amount of their revenue.

[01:07:12]  Bruce: Interesting.

[01:07:13]  Cameo: Yeah.

[01:07:13]  Unidentified speaker: All right.

[01:07:14]  Cameo: Well, this has been a fun conversation.

[01:07:17]  Bruce: It has been. Thank you for bringing it up. I hope we'll have more interesting conversations like this. I would like to see this area of how do we apply creativity to other areas. I think that's always an interesting subject.

[01:07:30]  Cameo: Yeah, I do, too. All right. Well, thank you, Bruce and Tracy.

[01:07:33]  Bruce: All right. Thank you.

[01:07:34]  Unidentified speaker: Thank you.

[01:07:36]  Bruce: Bye-bye. The Theory of Anything podcast could use your help. We have a small but loyal audience, and we'd like to get the word out about the podcast to others so others can enjoy it as well. To the best of our knowledge, we're the only podcast that covers all four strands of David Deutsch's philosophy, as well as other interesting subjects. If you're enjoying this podcast, please give us a five-star rating on Apple podcasts. This can usually be done right inside your podcast player, or you can Google The Theory of Anything podcast Apple or something like that. Some players have their own rating system, and giving us a five-star rating on any rating system would be helpful. If you enjoy a particular episode, please consider tweeting about us or linking to us on Facebook or other social media to help get the word out. If you are interested in financially supporting the podcast, we have two ways to do that.

[01:08:26]  Bruce: The first is via our podcast host site, Anchor. Just go to anchor.fm slash four dash strands, F-O-U-R dash S-T-R-A-N-D-S. There's a support button available that allows you to do reoccurring donations. If you want to make a one-time donation, go to our blog, which is fourstrands.org. There is a donation button there that uses PayPal. Thank you.