WEBVTT - Simplicable's Fundamental Principles of Technology 0:00:04.440 --> 0:00:12.200 Welcome to tech Stuff, a production from iHeartRadio. Be there 0:00:12.240 --> 0:00:15.720 and welcome to tech Stuff. I'm your host, Jonathan Strickland. 0:00:15.760 --> 0:00:18.680 I'm an executive producer with iHeartRadio. And how the tech 0:00:18.720 --> 0:00:21.360 are you today? I thought I would talk about a 0:00:21.400 --> 0:00:26.040 few fundamental principles that underlie technology, at least as identified 0:00:26.079 --> 0:00:29.880 by a blog called Simplicable. The name of the author 0:00:29.920 --> 0:00:32.559 on all the articles I was looking at was John Spacey, 0:00:33.320 --> 0:00:35.440 so it appears to be John Spacey at the helm 0:00:35.560 --> 0:00:37.960 of this blog, which I think is based out of Singapore. 0:00:38.680 --> 0:00:43.600 So these are concepts that apply to or drive technology 0:00:43.640 --> 0:00:47.880 and technological change and innovation. And it goes beyond things 0:00:47.920 --> 0:00:52.479 like circuits or electricity or mechanical systems or anything like that. 0:00:52.560 --> 0:00:58.520 These are more like ideas and observations that underlie technology, 0:00:59.640 --> 0:01:03.160 again as identified by Simplicable. So I don't wish to 0:01:03.200 --> 0:01:08.720 suggest that these are universal fundamental principles, just rather that 0:01:08.800 --> 0:01:12.120 I came across this list Unsimplicable and I thought it 0:01:12.160 --> 0:01:13.920 was interesting, so I thought I would talk about some 0:01:14.240 --> 0:01:18.119 of them today. So first up, we've got a concept 0:01:18.160 --> 0:01:22.720 that ties in with Moore's law to an extent. You 0:01:22.800 --> 0:01:26.280 could argue that Moore's law is another fundamental principle. In fact, 0:01:26.319 --> 0:01:30.200 it's one of the ones that's listed by simplicable. I 0:01:30.240 --> 0:01:33.520 think that's going a little far to call it a 0:01:33.520 --> 0:01:38.959 fundamental principle. It's certainly an observation that people have attempted 0:01:39.000 --> 0:01:46.040 to push beyond some pretty hard boundaries. But as a refresher, 0:01:46.120 --> 0:01:48.080 just so that you understand what I'm talking about here, 0:01:48.640 --> 0:01:52.960 Moore's law stems from an observation that Gordon Moore paid 0:01:53.000 --> 0:01:56.000 back in the middle of the last century, actually, when 0:01:56.040 --> 0:02:00.240 he saw that economic and technological factors were contribute meeting 0:02:00.320 --> 0:02:05.280 to a system where there was an economic demand for 0:02:05.400 --> 0:02:11.560 progressively more powerful microprocessors and later on computer chips, and 0:02:11.560 --> 0:02:16.280 that this demand in turn created an incentive for fabrication 0:02:16.360 --> 0:02:19.240 companies to come up with ways to meet that demand. Like, 0:02:19.280 --> 0:02:23.240 it wasn't just magical that the fabrication companies were able 0:02:23.240 --> 0:02:26.680 to make more powerful processors. They saw the demand there 0:02:26.720 --> 0:02:29.200 and then they said, okay, well, how can we make 0:02:29.280 --> 0:02:33.120 something that meets that demand. It's not just magically happening 0:02:33.120 --> 0:02:36.040 on its own. So every so often we would see 0:02:36.040 --> 0:02:40.639 companies find new ways to fit more discrete components onto 0:02:40.720 --> 0:02:45.080 a square inch of silicon wafer. As they were able 0:02:45.080 --> 0:02:49.200 to a couple of years previously. So generally speaking, the 0:02:49.320 --> 0:02:53.960 law of Moore's law boiled down to every eighteen to 0:02:54.040 --> 0:02:57.440 twenty four months, fabrication companies would find a way to 0:02:57.639 --> 0:03:01.359 double the number of transistors that they could it onto 0:03:01.560 --> 0:03:06.120 a silicon wafer an inch of silicon wafer square inch. Now, 0:03:06.120 --> 0:03:11.440 over time, this concept morphed into a similar but different one. 0:03:12.400 --> 0:03:14.440 We still call it Moore's law, but now we don't 0:03:14.480 --> 0:03:18.919 necessarily say that the processors of today have twice as 0:03:18.960 --> 0:03:22.480 many transistors on it as the processors from two years ago. 0:03:22.520 --> 0:03:26.320 For example, now we say every two years or so 0:03:27.280 --> 0:03:30.840 the chips that fabrication companies are producing are twice as 0:03:30.880 --> 0:03:34.160 powerful as the ones from two years earlier. So, in 0:03:34.200 --> 0:03:36.520 other words, if you bought a high end processor in 0:03:36.560 --> 0:03:40.200 twenty ten, and then you bought another high end processor 0:03:40.360 --> 0:03:43.600 in twenty twelve, the twenty twelve one should be twice 0:03:43.600 --> 0:03:47.200 as powerful as the twenty ten one, And then in 0:03:47.200 --> 0:03:50.280 twenty fourteen, if you bought one, that chip should be 0:03:50.320 --> 0:03:52.600 twice as powerful as the one that you had bought 0:03:52.640 --> 0:03:56.680 back in twenty twelve. Now we also tend to get 0:03:56.720 --> 0:03:59.560 a little loosey goosey with a whole concept of what 0:03:59.680 --> 0:04:04.160 power means in this context. Often this comes down to 0:04:04.320 --> 0:04:10.360 processing speed, how fast can the chip process information, how 0:04:10.400 --> 0:04:16.120 fast can it complete executions of operations, But powerful can 0:04:16.200 --> 0:04:20.840 also include some other concepts like bitwidth, and you can 0:04:20.880 --> 0:04:23.479 think of bitwidth as how large of a chunk of 0:04:23.560 --> 0:04:28.560 data can this processor handle. So if the bitwidth is greater, 0:04:29.080 --> 0:04:33.120 the processor can handle larger chunks of data. To me, 0:04:33.279 --> 0:04:36.000 one interesting thing about Moore's law is how we choose 0:04:36.040 --> 0:04:39.520 to interpret it so that it will remain relevant over 0:04:39.560 --> 0:04:43.200 the years. Because pretty much everyone has acknowledged we're running 0:04:43.279 --> 0:04:46.880 up against some obstacles that are just impossible to get 0:04:46.880 --> 0:04:49.400 around based on the technology we have developed so far. 0:04:50.480 --> 0:04:53.120 Let me explain that a little bit more so. As 0:04:53.200 --> 0:04:56.120 you reduce the size of these components so that you 0:04:56.160 --> 0:05:00.080 can fit more of them onto a silicon wafer, you 0:05:00.120 --> 0:05:03.920 start getting down to a size where you're encountering issues 0:05:03.960 --> 0:05:10.120 with quantum mechanics, and these quantum mechanics issues are not 0:05:10.920 --> 0:05:14.440 in alignment with the way that we want our electronics 0:05:14.480 --> 0:05:17.880 to work. Essentially, we get to a point where the 0:05:17.920 --> 0:05:22.080 pathways we have created for electrons are so small that 0:05:22.240 --> 0:05:25.520 the electrons have the potential to exist in a different 0:05:25.560 --> 0:05:28.560 part of the pathway than where we want them to be. So, 0:05:28.760 --> 0:05:32.679 if you think of transistor gates as actually being physical gates, 0:05:33.360 --> 0:05:35.479 as in, you know, you're when it's closed, you're not 0:05:35.520 --> 0:05:38.880 allowed to go through once you get to a certain size, 0:05:38.920 --> 0:05:41.240 there's a potential for an electron to be on the 0:05:41.279 --> 0:05:44.440 other side of the gate without having to actually physically 0:05:44.480 --> 0:05:47.279 pass through the gate. It just means that there's the 0:05:47.400 --> 0:05:50.000 possibility that the electron could be on the other side. 0:05:50.040 --> 0:05:52.000 And as long as there's a possibility, it means that 0:05:52.040 --> 0:05:56.400 sometimes that's what happens. And if you can't control where 0:05:56.400 --> 0:05:59.479 the electrons are, then the gates mean nothing, and it 0:05:59.520 --> 0:06:02.600 means that you're going to get computational errors. So there 0:06:02.640 --> 0:06:05.960 are fundamental physical limitations to how small we can make 0:06:06.040 --> 0:06:09.680 things if they're working the way that we have designed 0:06:09.760 --> 0:06:13.000 microprocessors for you know, the better part of a century. 0:06:14.120 --> 0:06:17.960 So that means that we have to come up with 0:06:18.000 --> 0:06:22.039 other means, other ways to try and eke out more 0:06:22.120 --> 0:06:27.159 performance in these chips. If we want Moore's law to 0:06:27.200 --> 0:06:30.720 remain relevant, and that's only if we say, all right, 0:06:30.720 --> 0:06:33.160 we want Moore's law to remain relevant, but not the 0:06:33.240 --> 0:06:38.000 original Moore's law. We're talking about our reinterpretation of that 0:06:38.120 --> 0:06:41.800 observation that was made, you know, in the middle of 0:06:42.160 --> 0:06:46.960 the nineteen hundreds. So that is kind of where we 0:06:47.000 --> 0:06:49.880 are with Moore's law. It's still sort of relevant, but 0:06:50.040 --> 0:06:53.599 mostly because we're willing to bend on how we interpret 0:06:53.720 --> 0:06:59.400 it and how we define it. So no one wants 0:06:59.400 --> 0:07:01.600 to reach a point where they have to admit that 0:07:01.680 --> 0:07:05.400 the rate of improvement is slowing down. No one wants 0:07:05.400 --> 0:07:08.159 to get to that point. So we'll just keep on 0:07:08.279 --> 0:07:11.320 moving things around, like doing the balls and cups routine, 0:07:11.960 --> 0:07:15.280 until we can no longer fool ourselves into thinking that 0:07:15.400 --> 0:07:18.920 we're able to keep this rate of change up. And 0:07:18.960 --> 0:07:22.040 this is what brings us up to a different fundamental principle, 0:07:22.120 --> 0:07:27.160 as defined by Sipplicable called accelerated change or accelerating change, 0:07:27.200 --> 0:07:29.800 I should say, and that's just what it sounds like, 0:07:30.240 --> 0:07:34.440 because we all realize that over time, stuff changes. Accelerating 0:07:34.560 --> 0:07:39.040 change means that the rate of change itself is changing. 0:07:39.480 --> 0:07:42.400 It's not just that things are changing day to day. 0:07:43.000 --> 0:07:46.640 It's the concept that they're changing more quickly than the 0:07:46.720 --> 0:07:49.360 rate of change was before, and that this is driven 0:07:49.400 --> 0:07:54.280 by technology and how we use that technology. So with 0:07:54.400 --> 0:07:56.760 this kind of concept, we would be able to look 0:07:56.760 --> 0:07:59.320 at any ten year span. So let's say we looked 0:07:59.360 --> 0:08:03.560 at nineteen fourteen to nineteen twenty three, and then let's 0:08:03.600 --> 0:08:08.000 say we compared that with a more recent ten year span, 0:08:08.080 --> 0:08:12.240 so let's say twenty fourteen to twenty twenty three. Then 0:08:12.280 --> 0:08:15.720 we ask the question in which of those ten year spans, 0:08:15.720 --> 0:08:19.480 In which of those decades would we see more change? 0:08:19.960 --> 0:08:21.840 And if we want to get specific, where did we 0:08:21.880 --> 0:08:27.160 see more technologically driven or oriented change. Since the nineteen 0:08:27.200 --> 0:08:30.680 fourteen to nineteen twenty three decade predates the invention of 0:08:30.720 --> 0:08:33.920 the transistor, it's pretty easy for us to say, well, 0:08:34.440 --> 0:08:37.600 the most recent decade has seen way more innovation driven 0:08:37.640 --> 0:08:42.520 by technology. It's not even comparable. And that's true, but 0:08:42.559 --> 0:08:45.679 we should also remember once again, these advancements in technology, 0:08:45.679 --> 0:08:50.600 they're not happening in a vacuum. It's not like technology, 0:08:50.679 --> 0:08:53.960 if left to itself, will evolve and improve over time. 0:08:54.360 --> 0:08:58.320 Stuff in the world shapes our approach to technology, and 0:08:58.360 --> 0:09:01.880 then our technology shapes the stuff in the world and 0:09:02.000 --> 0:09:06.280 our interaction with it. So in nineteen fourteen, you would say, well, 0:09:06.280 --> 0:09:10.600 what kind of factors were influencing technological development. In nineteen fourteen, well, 0:09:10.640 --> 0:09:13.000 there was a big one. It was the Great War, 0:09:13.320 --> 0:09:16.160 which was later called World War One. They didn't call 0:09:16.200 --> 0:09:18.600 it that at the beginning because there were still optimists 0:09:18.640 --> 0:09:21.680 back then. They weren't expecting there to be a second one. 0:09:21.880 --> 0:09:23.840 In fact, they called it the War to End all wars. 0:09:24.120 --> 0:09:29.040 It turns out that was wrong. Anyway, this war spurred 0:09:29.320 --> 0:09:33.360 a ton of innovation as various countries tried to find 0:09:33.360 --> 0:09:36.280 more efficient ways to kill the enemy while sustaining fewer 0:09:36.320 --> 0:09:38.560 losses of their own, or at the very least just 0:09:38.640 --> 0:09:40.960 killing war of them than they managed to kill of us. 0:09:41.640 --> 0:09:45.880 So we got lots of stuff like machine guns, motorized 0:09:45.960 --> 0:09:51.839 military vehicles, airplanes were used in warfare. Chemical warfare became 0:09:51.880 --> 0:09:54.840 a thing. We also got some other stuff that wasn't 0:09:55.040 --> 0:09:58.560 expressly made to kill people, like gas masks which was 0:09:58.559 --> 0:10:02.800 meant to save people, and field radios. Anyway, my point 0:10:02.840 --> 0:10:07.080 is that the concept of accelerating change isn't something that 0:10:07.080 --> 0:10:09.600 we can just isolate from the rest of the world. 0:10:09.960 --> 0:10:13.079 It's also something that can lead people to make predictions 0:10:13.080 --> 0:10:16.199 that I think may at best be a long shot. 0:10:16.600 --> 0:10:20.359 It's what has fueled a ton of discussion around concepts 0:10:20.480 --> 0:10:24.280 like the singularity. This is this idea that we reach 0:10:24.320 --> 0:10:27.880 a point where change is happening so quickly and it's 0:10:27.920 --> 0:10:31.720 so constant that there is no way that you can 0:10:31.840 --> 0:10:35.120 meaningfully talk about the way things are, because by the 0:10:35.160 --> 0:10:37.520 time you're done making a sentence, they ain't that way 0:10:37.559 --> 0:10:42.160 no more. They've changed already. So this idea, which relates 0:10:42.200 --> 0:10:45.400 to other concepts like humans becoming something more than human, 0:10:45.960 --> 0:10:51.200 the so called transhuman approach. Transhuman in this case meaning 0:10:51.520 --> 0:10:55.680 something beyond humanity. It doesn't have anything to do with 0:10:56.320 --> 0:11:01.240 something like the transgender community. That it's a different thing, 0:11:01.840 --> 0:11:05.880 very important thing, but different. This concept of transhumanism is 0:11:05.880 --> 0:11:09.520 about no longer being strictly human the way we would 0:11:09.559 --> 0:11:13.240 define it today, and that could include lots of things. 0:11:13.720 --> 0:11:17.880 It usually includes some form of augmented intelligence. Either we 0:11:17.960 --> 0:11:21.040 figured out a way to boost our own biological intelligence, 0:11:21.800 --> 0:11:24.679 or we've incorporated technology into us in some way that 0:11:24.679 --> 0:11:29.199 that then boosts our intelligence. Sometimes we also have an 0:11:29.200 --> 0:11:33.520 idea of digital immortality thrown in there. Mostly it feels 0:11:33.559 --> 0:11:35.920 a lot like stuff that's in the realm of science 0:11:35.920 --> 0:11:38.760 fiction rather than stuff that's in reality. But I would 0:11:38.840 --> 0:11:41.800 argue that it's based on this perception that change is 0:11:41.880 --> 0:11:45.800 happening faster with every passing year. And if that's your 0:11:45.840 --> 0:11:48.560 basic argument, well, then it stands to reason that at 0:11:48.600 --> 0:11:52.200 some point the rate of change will be such that 0:11:52.200 --> 0:11:55.160 there will be no meaningful way to quantify it. But 0:11:55.360 --> 0:11:57.800 like Moore's law, I would say this belief is based 0:11:57.840 --> 0:12:01.720 off things that may not be universally or permanently true. 0:12:02.400 --> 0:12:06.200 I think one of the mistakes that some futurists make 0:12:06.880 --> 0:12:09.960 is that they equate all change with what we see 0:12:10.040 --> 0:12:14.400 in things like Moore's law, because Moore's law describes exponential 0:12:14.520 --> 0:12:19.400 rates of improvement right with at least with processor complexity, 0:12:19.440 --> 0:12:23.640 which then we redefined as processor power or performance, So 0:12:23.679 --> 0:12:27.120 that same rate of change would then apply to everything 0:12:27.240 --> 0:12:30.280 with the way some futurists frame stuff out. But that's 0:12:30.360 --> 0:12:34.800 just not true. We don't see exponential change in everything 0:12:34.840 --> 0:12:37.560 that's related to technology. Some things actually change at an 0:12:37.559 --> 0:12:41.120 even faster rate, they might start to approach a hyperbolic 0:12:41.280 --> 0:12:45.120 rate of change, But some things experience much slower change. 0:12:45.160 --> 0:12:48.320 They don't advance that quickly, like battery technology does not 0:12:48.480 --> 0:12:53.040 advance nearly as quickly as microprocessor technology. So it appears 0:12:53.040 --> 0:12:55.000 to me that the singularity is going to require a 0:12:55.000 --> 0:12:59.280 lot more than just super fast processors, unless we decide 0:12:59.320 --> 0:13:02.320 to redefine what the singularity is, and then we could 0:13:02.320 --> 0:13:05.320 say we're already in it because we've redefined it, which 0:13:05.400 --> 0:13:07.280 we kind of have done with Moore's law. I guess 0:13:07.320 --> 0:13:11.480 we could do that, but it's not very satisfying. So 0:13:11.600 --> 0:13:15.160 accelerating change is one of those fundamental ideas in tech 0:13:15.200 --> 0:13:17.920 that may or may not apply depending on the tech 0:13:18.240 --> 0:13:21.480 type we're talking about. I would say that for some technologies, 0:13:21.600 --> 0:13:26.840 like autonomous vehicles, for example, we have not seen accelerating change. Instead, 0:13:26.880 --> 0:13:32.280 we saw an initial burst of innovation, incredible innovation, and 0:13:32.360 --> 0:13:35.760 for a few years that continued and it did look 0:13:35.800 --> 0:13:39.880 like it was accelerating change. But now we're seeing engineers 0:13:39.920 --> 0:13:44.400 having to hone in on specific limitations and problems and 0:13:44.480 --> 0:13:50.360 challenges within autonomous vehicle technology, and these require careful solutions, 0:13:51.080 --> 0:13:53.560 and some problems might be accounted for, but lots more 0:13:53.840 --> 0:13:56.520 have been discovered or are not accounted for, and we 0:13:56.559 --> 0:14:01.480 aren't seeing accelerating change in that field anymore. Iterative changes, 0:14:02.040 --> 0:14:04.800 which is still good, like we're still seeing advancements, but 0:14:04.840 --> 0:14:09.000 it's not going at this you know, breakneck speed. That 0:14:09.120 --> 0:14:13.080 accelerating change suggests. Okay, we've got a lot more principles 0:14:13.120 --> 0:14:14.960 to cover. I think it's time for us to take 0:14:15.040 --> 0:14:26.360 a quick break. All right, we're gonna move on to 0:14:26.560 --> 0:14:31.600 a different fundamental principle that Simplicable has identified as being, 0:14:31.720 --> 0:14:37.280 you know, fundamental to technology. And so let's talk about complexity. 0:14:37.320 --> 0:14:40.920 You can think of complexity falling into one of two categories. 0:14:41.080 --> 0:14:46.760 Simplicable calls it essential complexity and then accidental complexity, or 0:14:46.760 --> 0:14:50.440 what I would refer to as non essential complexity. Now, 0:14:50.520 --> 0:14:54.880 if something has essential complexity, that doesn't necessarily mean there's 0:14:55.000 --> 0:14:58.480 no way to simplify the technology. It might be possible 0:14:58.480 --> 0:15:02.840 to simplify it, but it's essential complexity. That means that 0:15:02.920 --> 0:15:06.680 if we were to try and simplify this technology, to 0:15:06.760 --> 0:15:10.600 streamline it or remove features or anything like that, then 0:15:10.880 --> 0:15:14.400 in the process, we would also reduce the usability or 0:15:14.560 --> 0:15:18.760 value of that technology. So, in other words, we could 0:15:18.800 --> 0:15:21.640 make it less complex, but we would also make it 0:15:22.000 --> 0:15:26.800 less good, or less desirable or less useful. This can 0:15:26.960 --> 0:15:30.960 fall into subjective perceptions. It's not just an objective truth. 0:15:31.360 --> 0:15:33.800 So for example, let's say you've got a team and 0:15:33.800 --> 0:15:40.560 they're developing a smartphone, and their initial lineup of features 0:15:41.120 --> 0:15:43.600 are all the typical ones you would find in a smartphone. 0:15:44.400 --> 0:15:46.720 It'll be able to make calls, they'll be able to 0:15:46.800 --> 0:15:50.200 send and receive emails and text messages. It'll be able 0:15:50.240 --> 0:15:54.200 to take photos, all that kind of stuff. The complexity 0:15:54.440 --> 0:15:58.560 necessitates certain design decisions, right, Like, in order to achieve 0:15:58.720 --> 0:16:02.200 the things you have listen did as what the smartphone 0:16:02.240 --> 0:16:05.280 has to do, you've got to make certain design decisions 0:16:05.320 --> 0:16:08.840 to support it. This all is just logical, right, And 0:16:08.880 --> 0:16:11.520 that could range from everything from the size of the 0:16:11.520 --> 0:16:13.720 battery you're gonna need if you want to have a 0:16:13.840 --> 0:16:16.960 useful phone life so it lasts at least a day. 0:16:17.880 --> 0:16:20.720 It may involve things like screen resolution. You want to 0:16:20.720 --> 0:16:22.880 make sure that people can see whatever it is that's 0:16:22.920 --> 0:16:26.640 being displayed. There, process or power to support all these 0:16:26.640 --> 0:16:31.720 different functions, Like, all these things become necessary considerations in 0:16:31.800 --> 0:16:34.400 order to provide a good experience. But let's say there's 0:16:34.440 --> 0:16:37.120 someone on your team who just doesn't see the value 0:16:37.160 --> 0:16:39.680 in having a camera and a smartphone. Maybe this person 0:16:39.720 --> 0:16:43.080 never uses the camera on their smartphone at all. Maybe 0:16:43.120 --> 0:16:45.680 they just don't take pictures. They don't see it as 0:16:45.720 --> 0:16:51.000 being fundamentally important to a smartphone's design. They could argue 0:16:51.080 --> 0:16:55.479 that you could drastically simplify the design of the smartphone 0:16:55.480 --> 0:16:57.960 if you just ditched the camera right. That means you 0:16:57.960 --> 0:17:00.440 get rid of the lenses, you get rid of all 0:17:00.440 --> 0:17:03.400 the sensors, you get rid of all the stuff that 0:17:03.560 --> 0:17:05.960 otherwise would have to be in the smartphone for the 0:17:06.000 --> 0:17:08.720 camera to work. And then you could either make the 0:17:08.800 --> 0:17:12.080 smartphone smaller, you know, create a smaller form factor because 0:17:12.480 --> 0:17:16.440 it no longer has to house those components, or dedicate 0:17:16.480 --> 0:17:20.119 that space for something else. Or even this could precipitate 0:17:20.119 --> 0:17:22.760 into changes for things like the battery life and the 0:17:22.800 --> 0:17:25.000 processor because it no longer would need to support the 0:17:25.040 --> 0:17:28.080 functions of a camera like these are sort of a 0:17:28.119 --> 0:17:32.800 cascading list of decisions that this could affect. However, someone 0:17:32.840 --> 0:17:35.680 else might say, well, this smartphone has no camera. It's 0:17:35.720 --> 0:17:38.560 not a good smartphone. I would argue it's not even 0:17:38.560 --> 0:17:40.520 a smartphone at all because there's no camera in it, 0:17:41.320 --> 0:17:46.320 And to them, the reduction in complexity has resulted in 0:17:46.520 --> 0:17:50.920 a reduction of usability or value. Again, there's no objective 0:17:50.960 --> 0:17:54.120 truth here. It's all dependent upon how you feel about it. 0:17:54.640 --> 0:17:57.639 But there is a general understanding that technologies can only 0:17:57.720 --> 0:18:01.760 be simplified and made more efficient and less clunky up 0:18:01.800 --> 0:18:04.240 to a point, and once you get beyond that point, 0:18:04.320 --> 0:18:06.520 you start to lose whatever it was that makes the 0:18:06.560 --> 0:18:09.240 technology useful in the first place. Now, if we go 0:18:09.359 --> 0:18:14.280 to accidental or non essential complexity, we've got the opposite. 0:18:14.560 --> 0:18:20.560 This describes a technology's tendency to have functions or features 0:18:20.840 --> 0:18:25.199 or elements to it that make it more complex but 0:18:25.840 --> 0:18:29.720 add no extra value to the technology itself, which means 0:18:29.880 --> 0:18:32.280 if you get rid of it, not only do you 0:18:32.400 --> 0:18:35.680 not eliminate something valuable, you might actually increase the value 0:18:35.760 --> 0:18:38.000 of the technology because you've gotten rid of some clutter. 0:18:38.520 --> 0:18:41.760 Now this could be software, it could be hardware. Like 0:18:41.800 --> 0:18:44.320 it doesn't have to be a physical technology. It could 0:18:44.359 --> 0:18:46.960 be something like a bug in software that when you 0:18:47.040 --> 0:18:50.280 eliminate it, not only does it make it less complex, 0:18:50.359 --> 0:18:53.600 but now the software works more effectively. So you've increased 0:18:54.240 --> 0:18:57.399 the value of the software. Even if you were to 0:18:57.520 --> 0:19:01.399 just argue that eliminating the bug reduces the size, like 0:19:01.440 --> 0:19:04.080 the data size of the software itself, you have increased 0:19:04.080 --> 0:19:08.160 its value, right because size is it's not an infinite 0:19:08.200 --> 0:19:12.320 resource that we have like your machines that run software 0:19:12.400 --> 0:19:15.640 have a limitation on how much they can handle. And 0:19:16.040 --> 0:19:19.520 if you start to reduce the demands of software by 0:19:19.560 --> 0:19:24.000 eliminating bugs, that increases that software's value, maybe not monetarily, 0:19:24.080 --> 0:19:30.080 but certainly from a process standpoint. So, with essential complexity, 0:19:30.119 --> 0:19:34.720 reducing complexity reduces the text value. With accidental complexity, reducing 0:19:34.720 --> 0:19:39.480 complexity increases the technology's value. Now there's a related tech 0:19:39.520 --> 0:19:42.040 issue I would like to kind of dip my toe 0:19:42.080 --> 0:19:46.560 in and mention here. That's called feature creep. Now, this 0:19:46.640 --> 0:19:49.760 is when a team is building out a technology and 0:19:49.800 --> 0:19:52.479 then they begin to add in features that were not 0:19:52.600 --> 0:19:56.800 included in the original plan for the tech. You know, oh, 0:19:56.840 --> 0:19:59.320 what if we were to add neon lights, or what 0:19:59.400 --> 0:20:01.920 about we put speakers on the outside of the car. 0:20:02.600 --> 0:20:06.480 Feature creep happens a lot in tech space. It can 0:20:06.600 --> 0:20:09.920 again happen in hardware and in software. It can also 0:20:09.920 --> 0:20:13.879 get to a point where it will doom a project 0:20:13.960 --> 0:20:16.760 or the very least delay it for ages and potentially 0:20:17.840 --> 0:20:20.520 mean that you end up with something that is less 0:20:20.640 --> 0:20:24.840 valuable because of all that feature creep, which ties into 0:20:24.880 --> 0:20:30.159 another fundamental principle that simplicable identifies where they say worse 0:20:30.359 --> 0:20:33.399 is better. By that, they mean not that if a 0:20:33.440 --> 0:20:36.919 technology is worse, it's better than a better technology, But 0:20:37.520 --> 0:20:41.800 sometimes a technology that has fewer functions but works really 0:20:41.840 --> 0:20:45.160 well is going to be viewed as more valuable than 0:20:45.760 --> 0:20:48.480 a device that has way more functions but it's harder 0:20:48.520 --> 0:20:51.480 to use, Which makes sense, right. If you make something 0:20:51.560 --> 0:20:53.800 that is easy to use and it does what it's 0:20:53.840 --> 0:20:56.760 supposed to do, then people are going to gravitate toward 0:20:56.800 --> 0:21:00.359 that more than they will technologies that it might have 0:21:00.680 --> 0:21:02.600 a lot more bells and whistles, but they don't do 0:21:02.600 --> 0:21:06.320 anything particularly well that doesn't typically stand the test of 0:21:06.359 --> 0:21:09.320 time well. Feature creep plays into both of these things here, 0:21:09.840 --> 0:21:14.920 both the complexity issue and the worst is better issue. Now, 0:21:14.960 --> 0:21:18.040 to me, the definitive example of feature creep, the one 0:21:18.080 --> 0:21:20.800 I would use if I were doing my TED talk 0:21:20.880 --> 0:21:24.439 on what feature creep is and why it's bad, would 0:21:24.480 --> 0:21:29.200 be the game Duke Nukem Forever. It was an infamous 0:21:29.240 --> 0:21:32.119 game while it was in development, and once it published 0:21:32.160 --> 0:21:34.399 it no longer became infamous. It just kind of became 0:21:34.720 --> 0:21:38.600 a bit of a punching bag, or sometimes just completely dismissed. 0:21:39.080 --> 0:21:42.080 So if you're not familiar with the Duke nucom franchise. 0:21:42.200 --> 0:21:48.560 It follows this overly macho male hero who's based a 0:21:48.600 --> 0:21:53.360 lot on characters that Arnold Schwarzenegger has played or Bruce Campbell. 0:21:53.480 --> 0:21:56.960 In fact, it lifts a lot of lines straight from 0:21:57.840 --> 0:22:01.880 the Evil Dead movies. Use Campbell Evil Dead movies when 0:22:01.880 --> 0:22:04.800 they were really campy and stuff. And it's a first 0:22:04.840 --> 0:22:07.320 person shooter game that a company called three D Realms 0:22:07.400 --> 0:22:10.760 originally announced in nineteen ninety seven. They'll keep in mind 0:22:10.800 --> 0:22:14.200 when studios announce a game, it typically means that they've 0:22:14.200 --> 0:22:16.959 already been working on it for a while, so they 0:22:17.000 --> 0:22:20.359 announced it in nineteen ninety seven, but the game wouldn't 0:22:20.400 --> 0:22:26.119 actually come out until two thousand and eleven. Now, video 0:22:26.160 --> 0:22:29.760 games can take a long time in development, but fourteen 0:22:29.880 --> 0:22:34.280 years is atypical, although Star Citizen might catch up in 0:22:34.320 --> 0:22:36.880 a couple of years if they don't have a full 0:22:37.000 --> 0:22:41.640 game released before then. And one of the many problems 0:22:41.840 --> 0:22:45.879 that was causing a lot of these delays was feature creep. See. 0:22:45.920 --> 0:22:48.479 While the team at three D Realms was working on 0:22:48.520 --> 0:22:52.320 the game, other companies were releasing updated game engines that 0:22:52.400 --> 0:22:57.520 supported more features, so you could build on the game 0:22:57.560 --> 0:23:01.440 engine you were depending upon already and continue building out 0:23:01.440 --> 0:23:04.359 your game. But the fear was that when Duke Nucom 0:23:04.440 --> 0:23:07.960 would release, it would look dated against games that were 0:23:08.200 --> 0:23:13.479 created on the more recent game engines. So you get 0:23:13.600 --> 0:23:16.840 the head of the project who suddenly demands that the 0:23:16.880 --> 0:23:20.560 team swaps to a different game engine, a more recent one, 0:23:21.200 --> 0:23:25.240 and that necessitates starting from scratch for most aspects of 0:23:25.320 --> 0:23:27.600 the game, like almost all the assets needed to be 0:23:27.720 --> 0:23:30.760 redone in order to work with this new game engine, 0:23:30.800 --> 0:23:33.480 and it sets the entire development process back to the beginning. 0:23:34.400 --> 0:23:36.480 Then you would have times where the leader of the 0:23:36.520 --> 0:23:39.199 project would want capabilities that were starting to show up 0:23:39.240 --> 0:23:43.240 in other games to then be incorporated into Duke nukeomb forever, 0:23:43.359 --> 0:23:47.359 when that had not been a consideration earlier in development. 0:23:47.760 --> 0:23:51.960 So as a result, the game was constantly going through development, 0:23:52.480 --> 0:23:57.000 then revisions, and sometimes complete restarts, and by the end 0:23:57.040 --> 0:23:59.359 of it all, I think it was pretty safe to 0:23:59.440 --> 0:24:02.880 argue that the game was filled with non essential complexity. 0:24:03.200 --> 0:24:06.800 And of course, by the time it finally published under 0:24:06.800 --> 0:24:10.800 a different company. At that point, because it had changed hands, 0:24:11.520 --> 0:24:14.520 it was no longer really a relevant game to the 0:24:14.600 --> 0:24:18.119 sensibilities of most gamers. You know, the even if the 0:24:18.160 --> 0:24:22.040 gameplay had been stellar and free of things like bugs 0:24:22.080 --> 0:24:25.960 and other issues. The tone of the game no longer 0:24:26.000 --> 0:24:30.520 fit what people wanted anymore because more than ten years 0:24:30.520 --> 0:24:33.639 had gone by since the game had been announced, and 0:24:33.720 --> 0:24:39.399 people's tastes in gameplay and game tone had changed in 0:24:39.480 --> 0:24:44.120 that time. So feature creep really was a huge problem 0:24:44.240 --> 0:24:48.960 for that game. Well, here's another concept that Simplicable includes 0:24:49.000 --> 0:24:54.240 as a fundamental principle of technology, the creativity of constraints. 0:24:54.320 --> 0:24:58.800 This one really speaks to me. Basically, this idea says 0:24:59.320 --> 0:25:03.840 it is much easier to be creative and innovative when 0:25:03.840 --> 0:25:09.320 you're working within some form of constraint, because constraints drive decisions, 0:25:09.960 --> 0:25:13.520 and if you are without constraint, you have no limiting 0:25:13.560 --> 0:25:16.440 factors that make it necessary to decide to go one 0:25:16.480 --> 0:25:20.520 way versus another. Any decision you make appears to be 0:25:20.960 --> 0:25:25.160 as valid and viable as any other decision you could make, 0:25:25.240 --> 0:25:29.000