Transcription

You are many things and I can't explain it properly. So you should introduce yourself. But yeah, your microphone is right here Yep, press hard for the next slide backwards and the pointer if you need it. Great. Thank you so much. Hi everyone I'm Peter. I'm going to kind of take things in a bit more of a philosophical kind of direction You know, I work for a research lab these days. So that's kind of my tendency The lab is called ink and switch We are interested in Carrying on kind of the work of like Engelbart and lick lighter and Alan Kay and these people we're interested in how computers can augment human intelligence and You know, that's very highfalutin. It's a lot of fun We get to dig into all kinds of weird corners of software and experimental interfaces and so on But before that I have written a lot of production software So I'm not just speaking to you from kind of an ivory tower perspective I was one of the early employees at a platform as a service company called Heroku I've run a lot of Postgres databases. I've worked in game development as well. I've built titles for DS and GBA I worked on this one teenage zombies invasion of the alien brain thingies for a Victoria BC game company and I've worked on desktop software like Songbird which was a cross-platform media player that lost fairly decisively And besides that I've also worked in research Spending some time on for example this ship here the Sir Wilfrid Laurier. It's a Canadian Arctic research icebreaker So I spent some time in the Arctic and that actually helped inform my perspective on things too, but we'll come back to that So I'm gonna start by kind of saying hold on a sec Before we get into kind of talking about why we can't make simple software We should probably define our terms a little bit and talk about what complexity actually is So the first thing I want to clarify is that complexity is not difficulty Right, just because something is hard doesn't mean it's complicated like the ideas of calculus might be very difficult to internalize but they're actually very simple and elegant and I also want to draw a distinction between something being complex or just being kind of big a Box of Lego is not necessarily a complicated thing though. You can make a lot of things with it Complexity occurs when your systems interact with each other okay, and when it takes a lot to Get things done because of that and more specifically I think the problem with complexity is that your systems can become unreasonable and when I say unreasonable I don't mean in kind of like a sort of colloquial sense What I mean is that you literally cannot reason about them you don't have the ability to predict what's going to happen And a lot of the time that's a problem because you got work to do and the thing is crashing and you don't know Why but a complex system can also be generative and surprising if you harness that complexity in positive ways Last before we get into it. I want to make just a very small detail point for the More pedantic in the audience. Some people draw a very specific difference between Complex systems from sort of chaos math and like emergent complexity We'll talk a little bit about that as distinguished from complicated systems where you have a lot of just kind of mess. I'm Kind of going to float back and forth across both of these without a lot of distinction because I think in this context Either one can cause similar effects Okay, so we are going to begin with a non-comprehensive look at complexity and More specifically we're going to kind of like picks cherry-pick some examples sort of from fake industrial sort of scenarios Where you can begin with something simple and end up with something complicated So I'm gonna start with like the most basic of all reasons why your software gets complicated and that's you know The first version of your code you just write the happy path Everything's glorious and and software can be really simple when it lives in an idealized world and everything is fine And so, you know, here's like a really simple imaginary, you know pseudo code web thing great We got a get request to our application, you know, we're gonna go fetch something from the database and say hello There's a hello world app of web apps server apps great and works fine You know if user 12 is me and user 10 is my friend Keiko and user foo is wait what? right We got to validate the input. Okay, so we'll validate the request now Okay, so we're validating the request and and that's good. And oh geez I'm not really handling it if we don't validate the request and wait, do I have to do this on every request? I guess I have to do this on every request and am I doing it the same way on every request? In Fact this exact pattern of validating user input and checking your arguments can lead to something that Brad us and Patterson call shotgun parsing and Shotgun parsing is kind of the idea that you know, you're parsing your input but it's like someone's taking a shotgun to your code base because it's just Blown through the whole code base and it can lead to very serious security vulnerabilities because you might carefully check an input in one place But not in another and there's a great talk from Rukon 2012 about this So, of course, you know now we're gonna be a little more careful. So we're gonna Also, you know if the database is down. We don't want to send a 500 we're gonna fail elegantly and as you go the more of these cases that you have to handle and the better the quality of Your code is right the more Conservative defensive thorough that you are like at this point now like the actual logic Of this method is beginning to disappear into all the edge case handling Right. We're well off the happy path now and so, you know, you can clean this up a little bit So for imagine here in this case that you know, we have a slightly Better set of libraries more thoroughly written set of libraries We've moved the complexity down out of this method and we're sort of saying like well The database won't throw an exception right because exceptions are ugly and kind of subtle to handle Well, it'll just it'll return null if it can't do the job for whatever reason and we're gonna say well, we'll you know There's like a good type system that's handling parsing the input ARGs before they get to us So, you know, we can we don't have to worry about that anymore and the value of well-written libraries and languages type systems and so on is that they can really Simplify your code make it less complex by preventing you from have to carry around all of this mental state everywhere that you go and You know kind of my observation of this world Is it like vigilance is not a strategy like we talked earlier about how you know, if a system fails, it's not oh Yeah, blameless postmortems. It's not that the the developer failed It's that the system failed You know If you have security vulnerabilities in your code because you didn't handle input the answer isn't to berate yourself or not handling the input You know, it's to step back to level up and say like well, hold on. Why do I have to do this manually every time? So sort of strategically you want to minimize the scope of failures and and kind of design them out of your system and one way To do that is to have a type system. So you don't you know, forget to check your nulls. There are other approaches I don't think this is universally true, but It's one way Okay, so let's talk about scale You know, we all know as an array gets bigger. You can have an O of n log n kind of sort algorithm great Okay, well, it's you know scales easy, right? So let's just imagine an admin panel for a web application you list your users looks kind of this Go to your database select all the users and then in your front and just show them all perfect easy. It's fine I've only got 10 users who cares? Okay. Well now we're at 10 to the 4. Okay, you've got a thousand users. So, okay. Well, okay We can't just render all that on one screen. Okay. Well, we're gonna use one of those offset SQL things, right? We know about this and then we're gonna need Impagination I guess and you got a click through. Okay. Yeah. Sure. We can still do this. This is fine Yeah, you don't want to request all that it's pain to scroll through. Okay. Well now we're 10 to the 6 users We've got a million Actually that offset thing that's a problem if you have a lot of users because in order to generate, you know page 850 it actually selects all of those rows and scrolls through them and just takes all of those results and just chucks them on the floor until it gets the ones that you asked about and Actually now even though nothing has changed about our problem statement like not only are the performance characteristics of the system starting to change and the user interface is starting to change but the the way that we interact with the problem is Changing too because if you've got a million users the way to find a user is not to just like keep clicking next until you find them one page after a Page 350 I come on the J's. Okay, click forward to change the query arg to force it You know, we've all done these kinds of things when the tools didn't keep up with our admin systems But like the point I'm trying to make here is that you know, once you start to reach like a hundred million users You know, it's not even the same kind of problem anymore, right? The complexity that snuck in here is now that we have different responsibilities. There are ethical there are legal There are policy responsibilities You probably have a team of people at your organization who are responsible for dealing with abuse Some of these people are terrible and you want them off your platform and you can't find them right like it's a different thing And it's complicated because the environment has changed as much as anything else So everything changes When your scale changes, it's not just like an algorithmic thing It's also the kinds of things that you're doing change and like in general my advice to someone who's built a lot of high-scale Production systems through many orders of magnitude is that it's as Harmful to build for the system of the future as it is to build an insufficient system for the present You know If you build the tools for a hundred million users when you have a hundred users They're gonna be completely unusable too and you're gonna waste so much time trying to solve problems You don't have yet But you're gonna miss out on all the benefits of being able to just Look at all your users and see who they are and talk to them, right? So you need to be scale appropriate and kind of be looking ahead Another way software can get complicated is with leaky abstractions. And so here we have a platform that's a little bit skewed And so complexity can kind of bubble up from under the waterline through these imperfect extractions abstractions This is how you copy a string. It's a nice handmade low-level This is an excerpt from Kernighan and Ritchie 1988 second edition It's the programming language and this book was such a revelation for me like how it showed me the way kernel Functions were really implemented No, I'm just kidding. They're not really implemented like this and they say here that this is how you know A C programmer would prefer to write string copy The the C programmer in question has never forgotten to null terminate a string I see but this is how string copy is actually implemented as of 2022 for alpha in In Linux and actually this isn't how string copy is implemented. This is like one page of assembler there's like 300 lines of assembly and really importantly and Intriguingly, although the interface remains the same modern CPU architectures have so many more constraints around Memory alignment and everything else that although the interface is preserved you can pass any pointers in and get values back the kind of performance Characteristics of like doing an unaligned versus an aligned string copy will be dramatically different And so complexity here, right? Like I think we can kind of call this a win, right? Like we've got this superpowered computer under the hood now, but it still kind of feels like that old jalopy They were running in 1988, you know, and like that's cool that it works, but In a sense this API that's so simple is actually undermining the value of the system and there's a lot of magic Happening to kind of hide this and so I feel very mixed about this because on the one hand, you know It's sort of like SQL databases where like you can add an index and change nothing else and things get faster But there's like a really important Subtle like lie that's being told here, but maybe this is good. And maybe it's bad This is like a value judgment kind of question and whether you understand this is happening could be completely irrelevant or it could be the difference between the success and failure of a project Okay, so these are kind of like technical Complexities that come in I want to talk about other sources of complexity different kinds of complexity and one really big source of Complexity in my projects. Maybe you're smarter than me and that's cool But it's when you have a gap between the problem you think you have or the problem you used to have And the problem you have right now and again, we're gonna use a toy example to illustrate this so you've got a users table just miss same app as before and You know your users is a bunch of fields You got a first name and a last name and how do you get the first name in the last name? It's easy Guys, you just split on a space As a van Harden Berg You can see how this might get you in trouble and in fact on my California driver's license It said that my middle name was van for many years And the problem here is that The model that you have for the problem doesn't actually map the problem domain successfully So, what do you what do you do? Right, and there are lots of things you can do you can rewrite from scratch You can patch around it and actually just as an aside for everybody in the room. The w3c has a wonderful Essay about personal names around the world and just you know, if you take one like little thing from this talk Don't use first name and last name don't use family name people's family names aren't accurate some people have them and others don't What you do is you have one field that is you know What is the full name and then the other one is if you need it, what should we call you? It's like a much better model Also Unicode I Know that's its own set of complexity, but And so, you know There's only so many things you can do when you have this problem Right and like I had a really specific concrete example of this in a distributed system recently Where like I had a mental model of how the system behaved and my tests Demonstrated that it behaved that way and then in my production environment it behaved completely differently because of behaviors that were not modeled by my understanding of the problem and this is part of why Distributed systems are so prone to this is because there's so many new free variables and and like articulation points where things can be fast or slow or where they can fail or You know arrive out of order and all these kinds of things and so when you have these kinds of model reality gaps You have to bridge them somehow. And so what can you do? Well, you can fix the problem you can improve your understanding and rewrite everything and like when you can do that It's probably best You Can't really always do that though and more to the point you may still not actually you can see the problem But you may still not actually understand the solution Right. And so what can you well you can hack around it, right? like I've put van Hardenberg into a lot of text boxes without a space in it and You know where the first letter is capitalized and the H is lowercase and that's not how I spell my name But it is how a lot of systems spell my name You know or you can ignore the problem right like maybe it's fine and like genuinely it could be fine for your use case You're just like well, I guess You know that Peter guy can suck it. He'll deal with having his name spelled wrong and I do you know It's these are options that you have and there's like a great You know like meme series out there on the internet lies programmers believe about pretty much anything like all time zones are one hour apart half an hour later in Newfoundland and So I think This is a this is a very fundamental source of complexity, but where things get really bad is when your problems start to multiply off each other and This of course is you know where you have kind of like compound interest on complexity So what happens if your problems? Dimensional eyes against each other. So again imagining this web application. You've got a bunch of different browsers to support You've got a bunch of different runtime environments to support different screen sizes network speeds different OS or browser versions And so if you want to actually understand what's happening, you know, all of these things multiply against each other, right? And so you don't just have one runtime environment. You might have one code base, but you have lots of different contexts So, how can you know that you actually have correct functioning code? Because you know the old joke about Docker like well worked on my computer. Well, I guess we'll ship your computer Well, even that doesn't really work because once you get out into the real world, there's different memory You know context so you're up against different loads or whatever else right? You don't actually control the whole environment and So this is what really starts to kill you with complexity, right and it's where all of those smaller inconsistencies play off each other to create an unknowably complicated environment and this is why you see so much popularity and Ember Ember general kind of hinting at this like you don't use the native API's because god help you if you're trying to like figure out how to map all of these totally different environments down to one consistent thing and like one solution here is just to only have one thing as best you can and to minimize the difference between those environments and that's why You see sort of like a sensibly lazy electron apps from big companies because even worse than having to support all these different things is having to coordinate all the different people and Teams to try and build features Right, and we've all many of us have been there, right? Like if you have an iOS and an Android team, like how do you get them to ship the same feature in the same quarter? Right, it's tough. It's tough Okay, so I Hope I've convinced you now that complexity is like a Complex problem itself and that it manifests in a lot of different ways So we're gonna change gears a little bit and talk about seatbelts and More specifically why seatbelts don't save lives And I have an asterisk here because it's a little bit of a controversial research topic But the sort of upshot of this is that in at least some studies they found that after seatbelts became mandatory in cars People still died on the roads at similar rates and that was really surprising because like You know seatbelts are a good idea like they keep you safer in the car and so somebody proposed this idea called risk homeostasis The idea behind risk homeostasis is that actually we die at a rate on the road Related to how much risk we're willing to take and so if you now have a seat belt and you're driving a car That's safer You're gonna go a little faster and you're gonna take the corners a little tighter because you feel better Right, so the the issue with making people safer was that they then took on more risky behavior Conserving their total risk tolerance. And so I think we see a similar thing in software, right? We call I call this complexity homeostasis, which is to say that if you have kind of a system that's evolving over time You know, everything's fine We're going along life is good. And then we add some more things and you know, we're still happy and then oh Yeah, now it's I don't like it anymore It's not good. It feels bad. Now. It's time for that rewrite that we were hearing about right? It's time to bring things back. Ah Okay, now we can go back to making things complicated again And So this is kind of like a set point So homeostasis is the process where our or it's any process where you sort of maintain a set point and it's commonly used to talk Also about how our bodies regulate temperature, but I think our organizations regulate complexity Right, and so all of us have different intuitions and people talk about wanting things to be simple there's like an aesthetic preference here and different people perceive that and pursue that differently and Like Davines, you know quest for just the right number of opcodes that we heard about yesterday is a great example We're like in a certain sense you know the correct number of opcodes is one and you could do that if you really wanted to but then you've got kind Of like the CISC, you know model where actually the correct number is hundreds because you're maintaining backwards compatibility and anything that can squeeze you You know either better numbers out of a benchmark benchmark or more CPU sales is acceptable and so, you know how you perceive what constitutes complexity or how much complexity you're willing to tolerate is an individual or an organizational decision and You know some things can actually move that up Like I have abandoned projects because they got complicated and annoying to work on But like some people might just tolerate that and not perceive it I've worked with some brilliant people who write the most complicated insane convoluted code from my perspective But when I sort of go to them, I'm like, this is so complicated and weird. Why did you do it this way? They don't see it because they're just much smarter than me They're able to hold that complexity in their head comfortably. And so for them, it doesn't feel that way Another way a system can become more complicated if it's worth a lot of money Right because like you can just hire another poor schmo to sling Java into the code base. I mean Has anybody here worked on an EA Sports title? Yeah, I'm so sorry. I Have heard some things man And it ships every year on Deadline without fail right like that's not an environment that leads to like healthy refactoring or reduction of complexity But you know what? It makes a boatload of money And so they'll hire people to work on it because they can afford to and you'll work on it because they'll pay you enough Because they know they know Right and so part of this as well is that also if you just have more people working on things You know you can tolerate more complexity I can hold part of it in my head and you can hold part of it your head and I kind of want to distinguish Like there's sort of the breadth of complexity and if you have a well factored system You can decompose the complexity either into layers or or modules, right? Like each individual Lego brick is simple that can build very complicated things from it Right, and so that's sort of the system complexity versus the component complexity CSS is incredibly complicated and by that what I mean, it's complex You can't tell from looking at one rule what it will manifest as in a final document So, okay. Well, we can just solve this problem with better tools, right? Well, no because as we've talked about we you know We have this homeostasis point that we fall towards over time and we can choose where to set it But we do move towards it and you know, the research on this actually goes all the way back to like the 1860s This is Jevons paradox, which was like why did coal consumption not decrease when? Engines became more efficient. The answer is people did more work Right, and so I feel very much that this is sort of the inevitable conclusion we have to draw from looking at the problem which is that the degree of Complexity of a system is tied to who we are and what we're doing over time Right, and so when we buy back some complexity by using better tools or by picking a simpler environment We're going to spend that out again eventually Okay, so let's talk a little bit about some theories of complexity because you know This I'm from a research lab and I like to like read papers. So this is not a new this is not a new problem Have people heard of cyclometric complexity before? Yeah, we're not gonna do this You're welcome But I do think that although you know sort of the naive pursuit of like software metrics as a way of measuring What we're doing is is not wise I think that the conceptual understanding that like when you couple things together that that's that can Have a cost and be problematic is worth thinking about in fact people have been looking at this and thinking about it since the 1980s this is Merrill Lyman in 1980s I triple e volume 68 So like this is not a new domain and so even back then this this edition was from 1980 The first paper published was in 1974 on these laws of software engineering. We're not gonna read these like super close so it's more that I want you to realize that like this kind of Recognition that systems grow to meet growing needs if they're successful is not a new idea It's a common problem and whether you're working, you know in building tools or languages, you know you might start with an elegant and simple thing, but as a system has more demands on it it responds by Adding right. That's that's a very common and it's a reasonable consequence And if you don't do those things the thing will often sort of starve and die One great paper if you haven't read it yet on this sort of topic is out of the tar pit by Mosley's from o6 and This paper differentiates between What is like accidentally complex versus essentially complex, right? So like essential complexity is like the irreducible like Non-eliminable part of your system, you know, if you are trying to model certain physical processes like, you know smoke or fire Like the physics part where you're actually doing the work. You can't get rid of that. You don't want to get rid of that That's what you're here for right? But the accidental complexity is all that other stuff like oh god, we gotta compile this and works on like Windows 11 has changed the ABI for this deal always like all that stuff where you you know, we heard about devine hoisting the phone up the the mast to download 11 gigs of something Right, that's mostly accidental complexity for our purposes and so it helps as you're working and thinking about complexity to to think about where you're spending that budget and whether it's Be whether you're being deliberate in terms of how you're adopting complexity The other thing I want to refer to is this great this great essay from the Berkeley DB team in the architecture of open source and Honestly, I highly recommend reading this if you just like software engineering the architecture of open source software is is a cool series and basically what they do is interview open source communities about Their software and have them write essays about what they've done and then they publish and share those but I think this Berkeley DB chapter in particular is exceptional and I think about this all the time, which is that software architecture degrades with changes made to software Right, so you might have the most elegant brilliant carefully planned system in the world But it does not exist at a single point in time in a vacuum and as new demands come along this architecture will decay And so it requires a constant shoring up and when you have big interfaces that you've invested heavily in and they're straining It can be extremely expensive to change them. I Also just love this. This is a little more handmade specific kind of vibe the Excel team motto At least according to Joel Spolsky is find your dependencies and eliminate them I have been told on reasonably good authority that Excel actually is built with its own C compiler that they they didn't even want to rely on other teams within Microsoft and you know to the degree where they've built their own compilers I Not saying you necessarily should do that I'm not saying you necessarily shouldn't you got to think about how you're spending your budget and And the last kind of point I want to make Sort of on this theme is again that complexity isn't necessarily bad, right? Like complexity can lead to all kinds of like wonderful emergent properties, right you the legend of Zelda You know Breath of the Wild It has had some such a wonderful community grow up around it precisely because they managed to tame complexity with their chemistry engine So there's a lot of emergent gameplay Properties and experiences that come out of Interactions complex interactions between systems, but the systems are factored in a way that enables and empowers us And of course if you're a roguelike fan, you know people have been doing this forever there Okay, so how now what You know, we we We have now looked at complexity. I've told you you can't get rid of it. So Just gonna have to live with it and you know better tools won't save us So, how are we going to spend this this complexity budget that we have? I Mean, you know one approach is you just put your head down and you work away and pretend it's not a problem And you know that that's a pretty common solution to all of our problems in life so we could do that But I'm gonna maybe try and propose a few ways we can cut the Gordian knot here and so, you know the the story of the Gordian knot was that there was this sort of This ox cart with a really complicated knot on the handle and people were like, oh whoever whoever unties this knot will rule all of Asia and many people had come and then Alexander the Great came along and Depending on the version of the story you hear you just like it's like, okay cool and he cut it the knife Right, and so instead of solving the problem by like trying to be really smart or work really hard Like can we just cheat and change the rules? I think that's a better approach So one approach is to do what folks here like to do is just start over You know, you can't actually get rid of this problem, but you can reset the clock on it Right, just build a new one start from the beginning. Everything's easy in the beginning It's only when you have users and features that you have complexity So like, you know make a new programming language start a new VM. It's good You can't really change this like long-run pressure But like genuinely you can reset the clock and I think that's part of why Things like Excel are popular and successful is they don't have package managers, right? Like every time you make a new Excel document, it's a brand new universe You know, but none of the misery or mistakes that you made before it's like the forgiveness of the blank page You know, that's then there's something to that. I went to a talk by John Romero At Strangeloop not that long ago and he talked about how id Software had been making these like shovelware games for as Contractors are that the id Software team him and him and Romero and Carmack had been Making these sort of shovelware games and their attitude was like well, you should just always start from scratch You get really good at it You can be really fast and each time you do a little bit better than the one before and we do I think do better Like I'm not I love learning new languages and building new ecosystems And I think a big part of the reason why they're successful is because when you have a new language You do have the opportunity to like clear away Like the standard library and also just the ecosystem of ideas and people and sort of start from a fresh starting point Now this won't cure complexity in the long run But you know, it can get better right at least in the midterm But you know it can get better right at least in the midterm and we can get further so I think you know That's pretty cool. And it's also pretty fun. So like I'm all for that. Please. Please do more of that and To some extent it's sort of like You know, it feels like we live in these Unbreakable regimes where like unity, you know rules or were like the big companies Google and Microsoft and everybody rules But that's the kind of thing that's true until it isn't and there's this lovely quote from Ursula Le Guin about Capitalism which is sort of you know, the generalization of these problems you know capitalism was itself an invention and You know, I'll just read it. We live in capitalism. Its power seems inescapable So did the divine right of Kings and any human power can be risk resisted and changed by human beings? Right, so we we should not doubt That the environment can be changed. The environment was created. It will be changed We don't know how or when but it is inevitable Okay, so you can start over revolution burn it down Or you know just do less Do less with less do I have my play date? Does it do people have these as they make out a play date? Yeah, this is great. It's black and white. It's there's only one platform It's small it comes in one color. It only has one color black or white depending on how you think about it It doesn't have a lot of buttons. Isn't that much RAM? Doesn't really have any there's a little bit of networking and there's only one hardware platform. So you don't have to worry about compatibility problems ish There there is the emulator which behaves differently and due to like sourcing problems. They had to get a different Microcontroller but it transpiles natively. They're doing a really good job. Anyway, it's a heck of a lot simpler than building for ps5 You know Xbox PC switch 3ds all on one code base like it is genuinely awesome and because it's so small it's like You know kind of appealing and when you have less scope you can choose to spend that energy that complexity budget You can put it into polish Right and like on a small platform a small idea can shine So, okay. Well, we can't solve complexity, but we can make things worse This is actually from augmenting human intellect by Engelbart in 1962 and it's demonstrating That you know, you can in fact change people's experience with design interventions, I Said change not improve So, yeah, you can we've made things pretty bad in terms of software development This is the my favorite slide always to show. This is the cloud native cloud cloud Foundation cloud native landscape. I was getting strong This is ostensibly I think 20 trillion dollars worth of companies Anyway, please memorize all of this will be a quiz at the end if you want to make a web application in 2022 I had to zoom out the browser just to fit it all on screen for this one So I'm gonna talk a little bit now about our research which kind of ties back into this because I think it might be interesting Our approach is less the kind of like reboot Model and more of them maybe do a little less with less model and one of our sort of research interests kind of builds on these sort of tools for thought a big part of What we're interested in as a research group is not simplicity versus complexity or decentralization or anything like that But we do find that we have to work in that space because what we want our tools that we have agency over that we have ownership of that are ours and can't be taken and So we call our research their local first software and The idea is basically that instead of having to go learn that whole chart of technologies that you know You can't actually do any of that stuff if you just run it on your computer because that stuff's all in the cloud So if you want to build software that works on your computer Not only do you not get to use all that stuff. You don't have to use all that stuff and So this you know, it's sort of like simplification like via amputation So we just cut off most of the cloud and then we build things locally And so, you know, we've dabbled in a bunch of different platforms over the years right now we're building things in the browser, but storing everything in like index DB, but one of our kind of core beliefs is that you know collaboration is such an important part of Thinking and making and doing that it should be like a really fundamental part of our platforms And so we've been exploring technology that allows you to build software that runs on your computer but then collaborates with other people, you know, even allowing online offline kind of cuts and the The model underpinning that is a data structure called auto merge It's sort of like a portable version JSON like data structure. You could think of it as like get for your data I don't I'm happy to talk at length about this stuff, but I don't really want to Harangue you too much on, you know, sort of our particular kind of like development interests, but It's really incredible just like how it feels to build software That's fast and simple and runs on your computer if you like me have spent the last You know chunk of your career building cloud services and and you know running things in the sky I had this like really memorable outage where Amazon Turned off u.s. East one dirty because the generators didn't come on in a hurricane and You know We were sort of like three days into some godforsaken Like system rebuild from backups of everybody's databases and my co-worker turns to me and he goes I'm fixing computers that don't exist In a data center, I've never been to for people I've never met And He just had the like thousand-yard stare and I was like, yeah Do you need some more coffee? Yeah But and so, you know like in a sense working on this stuff is almost like penance for me because I created all these single points of failure Anyway, so let's recap a little bit of all of this. How do we live our lives in this complicated world, right? So complexity Occurs when our systems have internal interactions, right? Complexity doesn't mean oh, there's a lot of stuff it's when all that stuff starts to bump against each other and cause unpredictable outcomes and Complexity is also a natural consequence of system incentives If you have a lot of people using a thing and you're listening to what they need and you're you know like evolving as you learn more you're going to end up with something complex and Better tools won't change this Right. The complexity is a consequence of who we are and the choices we make Sure, you can you can burn through your budget faster But like ultimately where your project ends up on the complexity scale is more about how much time and how many ideas are invested into it than anything else So we can't beat complexity, but we can get beaten by it right and so, you know, what are our coping strategies? Well, we can start over We can eradicate dependencies. We can cut scope do less, right? we can simplify our architecture and a really big one is being conscious of and learning to kind of identify when you're getting into these like multiplicatory Environments, right like it once you start porting things to multiple platforms and having to build those like per platform abstractions How do you manage that complexity back down? How do you isolate? Complexity and a big part of success is isolating complexity But I also want to you know, give a shout out to gazing into the abyss and You know, you can you can go go for it right like embrace complexity harness it Yeah, it's a deal with with an elder God and you may accomplish great and terrible things but at a great and terrible price Yeah, that's fine. But you when you do this, you've got to be real careful, right? and and you want to be really deliberate but deliberate about how and when you Take on that complexity. So I guess in in closing we can't solve complexity, but we can build better software Or to put it in the words of cyclist Greg Lamond, it never gets easier. You just go faster And that's all