 Hi, I'm Sam from the Developer Relations Team here at Google. And I'm here to tell you that it's OK to abandon all hope, to give up and to go back on your plans. Let me set the scene for you. As you plan your next release and you look at your code, it's very easy to fall into the trap of improving your code base rather than moving forward. You might consider having faster build times, more readable code, or to upgrade to the latest web framework that everyone's talking about. This happened to me back in November 2018 in the lead-up to releasing Santa Tracker, which is a holiday-themed experience for all ages. We were in the middle of a rewrite, mainly because our build times were enormous. And we wanted to use Google's new web components library, LitElement. But we made a hard decision to give up on our tech debt and to ship our old code base, because Santa only comes once a year. And by being busy refactoring a code base, we just weren't checking off our task list fast enough. So let's talk a bit about what we were dealing with. Santa Tracker, at its core, is a shell which hosts lots of smaller games or scenes, like this fun snowball throwing game here. And on December 24th, we unlocked the Tracker itself, where you can see Santa traveling around the world on his journey, delivering presents, and finding out when he'll arrive in your town. Some of these games have code that is years old. And as much as possible, we want to avoid throwing these games out in a rewrite. So in 2018, we decided to migrate about 50 different games to work on this new platform. And fundamentally, the rate we were getting through migration tasks just didn't equal our December 1st release date. And this is why we gave up. So we've now successfully migrated for 2019 and beyond. But what do we learn in the process? The first learning is the old idiom of, don't let perfect be the enemy of good, as it applies to developer experience versus user experience. I imagine that Santa Tracker would somehow be infinitely better for our users if we had a faster build time and a more modern stack. But the reality is that an upgrade would mostly help my team and have very little benefit to our end users. Keep in mind, of course, that sometimes your technical choices are changed from underneath you. And in our case, we were using HTML imports, which shipped in Chrome, but never really got wider adoption. The truth is, though, there's often really fewer reasons than we think as developers to change the stack. Secondly, we learned the value of allocating time to prototyping before you decided on a new technical stack. This can save you a lot of grief in technical debt. Technical debt is where you're on a tight deadline, and instead of properly solving some problem, you're patching over it and leaving it for your future self to solve. And of course, all software has technical debt, but it's even worse when you're blazing new paths like we were into a totally unknown framework or library. And for us, we didn't really allocate time for prototyping. We were on a tight schedule. We'd bought into this vision of a new amazing developer experience. But in practice, Santa Tracker, like every site, has edge cases that we didn't really plan for and didn't fit into the mold of this new stack, which we'd chosen, which caused us to incur this technical debt. Software always has innate knowledge. Our old Santa Tracker code base had years upon years of hacks and workarounds. And in any rewrite, it's enticing to skip these weird code paths. But in the end, they were there for a reason. By building a working prototype in a new stack, you can test these edge cases to see if they still matter to you. Because we skipped this step, we hit all sorts of challenges way late into our development cycle when it was just too late. We had to give up on the RIF factor. In hindsight, we should have built up all these tricky nuances of our site in a full prototype before attempting to replace the entire tech stack. What we ended up doing was what we're using what we built in 2018 as the prototype for what you now see in 2019 and beyond. Don't get me wrong. In 2019, we still shipped some of the best parts of the prototype. And that leads me to the final learning. Ship early and ship often. You always want to validate your technical choices with real users. So we'd ridden a whole new game, Elfmaker, entirely on the new stack. It wasn't part of the old code base whatsoever. So we felt comfortable testing it with real users. And in fact, if you look closely at how that scene loaded in 2018, you could see how we introduced a bit of magic, deferring to an iframe with a small shim between the code bases. We had to concoct a Frankenbild system to make this work. But as part of that, we forced ourselves to have an end-to-end build processor of the new prototype, even though we weren't shipping it wholesale. And this meant that our rewrite wasn't just wholly turned into just a prototype. And we've got a small slice of the new code in front of real users to show that it could work. We're hoping to open source the new version of Santa Tracker in early 2020. It's not perfect, but it is a real website with a bunch of build tooling, legacy code, and necessary technology choices. I hope you'll check it out and get some insights into how to best structure your next project. Remember, don't let perfect be the enemy of good. Your users don't care how the sausage is made. Ruminate on your technology choices by building a prototype. And if possible, try to get the safest parts of your code in front of real users, even if your whole refactor isn't done yet. Thanks for watching, and I'll see you next time.