 I love two teams. Thanks everyone for coming. So it was the best of times. It was the worst of times. Doesn't this describe software perfectly? It is also the worst of times because I have a terrible cough right now. So if I start hacking, we'll fix it in post. So this story starts with the company I work for, Tightrope Media Systems. We're a small company about 30 people based out of Minnesota. And we have two products, Cablecast and Carousel. Now Cablecast is our broadcast automation product. And if you don't know what that is, most people don't. If you've ever seen that movie Hackers, that scene where they hack in and control a TV station, that's our software. Not literally, but to my knowledge, we've never been hacked. And I don't think we control any of those really large VCR players. But essentially that's what we do. We run TV stations. Our other product, Carousel, is digital informational signage. So we literally put stuff on screens. And both these products are controlled via a web browser. And we've been doing this for quite a while. So our company was started in about 1996. And our current code bases, which we're actively maintained right now, predate Git. They're at least 10 years old. I have no idea when they came into first action before that, because there's just this one initial commit in the Git history. And I can't look back further. And the code is bad. So in this code snippet right here, there is XML generation, some database access. There's probably some SQL injection that could be happening. It's not good code. I'm not proud of this code. To my knowledge, we had about three versions of jQuery checked into our code base. Our HTML was still laid out using tables. I think we used iFrames for a while. We still do in one of our products, I'm pretty sure. And so we just didn't really like working on this code base anymore. The UI, especially, was just really old and dated. Even though our products might have all the features that our customers needed, they didn't like them. You judge a book by its cover, and this is how our customers felt about our products. And the developers, me, we didn't like working on our products because we didn't want to poke the bear. We didn't want to be the one that creates a bug. So we would actively avoid certain features, because we knew it would make us go into code that we didn't want to be in. And so here we are with two products that are old and dated, and we need to modernize them. And so what do we do? New logos. Ship it. So to further set up the story, about three years ago, we were all one big company. The salespeople all sold all the products. The engineers all worked on all the products. The developers all engineered all the products. And when three years ago, we decided to try changing this up a little bit, and we split into two teams. Those teams were completely separate. The salespeople on those teams only sold the one product. The engineers only engineered the one product, and the support people only supported the one product. And we thought this would be really awesome because it would allow people to have more focus on the product domain, yada, yada, yada. Around the same time, I was in grad school, and I had to build a tool to create processing schedules for real-time processors. And being a web developer, I was like, I'm going to do this as a web application. And I think I had just come from a RailsConf, and I had heard about we don't use Rails at all. It's just like that was the cool conference to go to at the time. But I was at a RailsConf, and someone mentioned Ember. And I'm like, all right, let's give this Ember thing a try. And it was amazing. It was just great. I got to build this front-end application. It was all new and modern and sweet. Our API was completely separate for the application. I built a little Rails RESTful API that provided the processor schedules. And it was amazing. I think I saw Tom and Yehuda at the RailsConf. I was like, yay. And so I'm on this newly formed team, and I go to my team. I'm like, hey, can we use Ember? And I got approved. And so I, at that point, started spiking on a new feature. We decided, hey, we have this new feature. It was video on demand. We needed to give our TV customers the ability to watch their videos on your iPhone, tablets, all that kind of stuff. And so it needed UI, needed some back-end stuff. And so I built the UI in Ember. We built the API, it was a new project, and it was completely separated from our old code base. And we got it completely done. It was really nice. It was really a pleasure to work in. We were really happy with the finished product. It was a completely separated code base that did this one feature, but did it really nicely. And so we're left with this conundrum. What do we do? We have this old application, Clippy. Our stack is a .NET base, so that's why our old code base is represented as Clippy. And we have a new code base, our Ember code base. And we're left with this question of where do we go from here? We can either rewrite the entire application or we can figure out a way to make these two things work together. And a little voice came to me and it was use the URL, Tom. And so it's dead simple. What we did to make these two applications work together is we linked to them. Now this might seem like a duh, but three years ago this was not duh. This was like no one had good routing support. No one had good URL support. It was JavaScript applications routinely just broke the back button and you couldn't, there's nothing in the URL so you couldn't link to anything. And if you think that's a solved problem now, go try using Twitter advanced search and hitting the back button. You lose your search. Or you ever get weird things when you hit a thing in GitHub and then you go back and there's two commits all of a sudden? Like the web is hard, URLs is hard, state management is hard, but Ember got it right and they got it right really early on. And so we basically were able to link between our two applications and provide state in the URL that allowed us to go from one application to another really easily. And it had a lot of benefits for us. First, it allowed us to ship that new feature now. The customer doesn't care about your process or about what framework you're using. Your customer wants their features, they want the value that that feature provides and we were able to deliver that really fast. Our old code base was really isolated from this change. We had to update a few links in the old code base but it was really very targeted change. It was pretty easy for us to ensure that we didn't break anything. We did a lot of manual QA at the time and we didn't have to muck around in the old code base to make it work with the new Ember app at all. And we saved so much time by just not rewriting the entire app but by just leveraging our old code with our new code. They were able to write a few other screens in Ember as well. So we wrote our new feature and then we had some extra time so we ported one of our screens from our old code base to our new Ember application. Now, this isn't without downsides. The one thing that comes up is you're now entering and exiting two different applications. You might go from one to the other and you'll get the dreaded flash of white. This ended up not being such a big deal for our customers because they were already used to a server rendered application. They were already used to clicking a button and waiting. And what was actually really nice is because we rewrote a few other screens, we focused on flows that would keep them in the Ember application. And so while they did have to transition more, they were already used to transitioning between a server rendered app anyway but the experience of staying inside of our Ember app when they could felt much faster. So those new features felt really good to them. The other issue that comes up and people ask me all about when you say this is continuity. Doesn't your customer get jarred going from one application to another? And that was a really simple answer. We just made it look like shit. You can use CSS for evil. So we made the CSS for our new application, replicate the crappy iframes and HTML layout that our table layout that we did in our old application. And so we kept it looking like crap across the board. So now on the other team, they decide on a Big Bang rewrite. And they start with a really amazing mockup. If this was a real web page and not just a screenshot, this thing is amazing. You can log in on it and all the icons in there, they flutter around before you log in. It seems really fully functional, except it's not. You can't actually do anything on it. All it did was really give our stakeholders and our salespeople, especially this false hope that we would be done in a week or two, like building this new application. And so the term Big Bang is really interesting because the origin of it, Big Bang Theory, is a rapidly expanding universe, right? And that's exactly what a Big Bang software rewrite is. It's rapidly expanding and will fill up all the space it can. Because every time you go to re-implement a feature, you're like, you know, I could do that better. Or what did that line of code do? We don't need that anymore. Or there's infinite ways to debate when you're rewriting an entire application. Meanwhile, your customers, they're still waiting on that new software. They don't get any value out of your new code until you ship it to them. And so the longer it takes you, and especially in a Big Bang rewrite, it takes a while, that's value you're not giving to your customers. The other thing is you're throwing away all the value that you had to begin with. That old code, even though you're afraid of it and it might have some bugs, it's being used by customers. They're getting value out of it. They paid you money for it. But you're just throwing that all away. And so at this point, our team, the broadcast team, doing the cable cast product, we had shipped some new Ember code. And the other team, they didn't really know where they were. They couldn't even really give a good estimate for how long it was gonna take them to do this rewrite. So some things happen, both teams. First thing we need to do is we need to hire some people. Now, this is kind of what our JavaScript code looked like. Inline functions in your HTML. It's pretty sweet. And when you're onboarding new people, the common way, especially how I got onboarded, is they mimic. They mimic the code they see around them. They paint happy little trees because they see other people painting happy little trees. Happy little function calls all over the application. And while you can make something that looks really good and works fine in the customer, I'm not gonna say like code is glorious. The point of code is to give your customer a product. The product can look great, but it might not really be what you wanted or how you would actually want to build it. And the other reason why I kind of used these wild, wild west slides for this is because the other problem with onboarding in this way where you don't have strong onboarding tools, and I'll get to that in a second, is that it's kind of the wild west, right? Every man for himself, I do what I want. And that was, I think, a problem on the other team. I wasn't on the other team, so I can't totally speak for it, but they definitely had an issue coming together on best practices. And that's not a problem that my team had. When we onboarded our new person, we were like, hey, we do Ember for our JavaScript. Go read the Ember guides. Get set up really well with Ember CLI. And what Ember really gave us was a starting point. It gave us our best practices, our tooling. It told us how we did JavaScript, and we were able to use that to tell our new person and help onboard him about how we do JavaScript. The other thing I want to talk about that affected both teams is workflow. So the other team, the signage team, at first, I think they did what was a more traditional workflow. So it's kind of like a game of that telephone game that kids used to play where you whisper in someone's ear, you whisper five times, and at the end you get something completely different than what the person started with. What they would do is they would start with really high-fidelity mock-ups. And then the front-end person would take that, turn it into some HTML and CSS. If you were here for Chris's talk, you realize that you can do things in Photoshop that you can't do in HTML and CSS. And then you would take that HTML and CSS, translation of the Photoshop document, and we'd give that to the back-end person who would go and turn it into, in our case, some razor templates for this MVC.NET framework. The problem there is it's not as bad as transitioning from the Photoshop to the HTML and CSS, but there's still that you might not be doing things as easy as they could be done if you were just doing them in the language in the beginning. And so there's a lot of areas for just dropping the baton, just losing that transition. And on our team, our workflow was Ember CLI. And I think Yehuda used a term production-ready prototyping. And that's what Ember CLI really gave us, is the ability to write code that when we're done with it, even though it's a prototype, we could ship it to production if we wanted to. And I relate it to Chipotle. So the way we worked was we would start writing some stuff in our Ember CLI app, I'd make some templates or some controllers, and I would get a feature sort of working. And I would kind of pass it along for the designer, excuse me, and some other people to work on. And at any point, just like any point where this burrito is coming down the line, I can pick it up and eat it. It's a working burrito, or a web application in this point. And it was really nice with Ember that the HTML bars and the CSS and the tooling really made it so that even though I was the JavaScript person and I knew the Ember framework really well, our other team members could hop right in, they would know where a template was, it looked like HTML, they could edit the CSS or the SAS, they got the auto-live reloading. So we could bring in other people that were more front end focused after the feature had been kind of spiked out and they could increment on it. And that worked so well for us. I can't even say like how valuable Ember CLI's tooling was in getting our product shipped. And so when we last checked in, here we were. The, our team had shipped some new Ember code and who knows what the other team is doing. We need to ship some more. So our team, we shipped some more Ember, sweet, more Ember. The other team, they had to do a release too, they can't just totally abandon their users. But they wrote some new features in their old framework. So they, the old code that we all hated, they did it the exact same way. And so while we both shipped new product, we gave our customer some value, yes. They actually moved backwards in their timeline because now that feature that they just wrote for their customer, they're gonna have to re-implement again in their Big Bang rewrite. And so they just actually lost ground. They got further away from their goal. So what else happens when you're software engineering? You get derailed. This has happened to everyone in the room. It can be a security issue, it can just be a really gnarly bug. It can be a sales thing that comes up, hey, if we do this, someone will give us a lot of money. And how can you say no to a lot of money? And so for the broadcast team, getting derailed was getting off the Ember train, right? We were stepping away from our incremental rewrite. And, but it was actually really pleasant. It was like a nice tourist overlay. Because when we got back, the Ember train was waiting for us. Ember had actually fixed some bugs of ours. They had added some new features that made things really awesome. They had gotten faster when we came back to working on our Ember application. It was really nice to stop working on a project, come back, do the quick upgrade and find it better than when I left it. It was like, whoa, that bug is fixed, sweet. The other team, when they got derailed, they had to come back and put it back together. And if you've, especially when you don't have something like Ember with its strong conventions, you write code, I do the latest blog post that shows me how to structure my jQuery. Then I go off and I work on other projects. I do some reading at night and someone shows me something that is like a way better way to organize my jQuery projects. And then I come back to that old project that I have to work on again. And man, I need to redo all this and I need to like, you know, upgrade grunt because it's not running anymore because, you know, MPM installed a different version this time. So there is just a lot of friction from getting on and off their project. As the head developers come on, come off, it was always changing. It just slowed them down. So this is where we last checked in. Our team had two Ember releases. The other team had chipped some old code. I'm sorry. So they're looking over our shoulders at this point. You know, they're doing their own reading. They see the Tomster. They're like, you know, this seems like a good idea. So they switched to Ember, but they don't go all in. And so they start, they swim upstream a little bit. They don't embrace all of Ember. And it's like swimming upstream into the mouth of the bear. And specifically what I'm talking about is actually Ember data. So both teams had to rewrite their APIs to kind of work with Ember. And our team, you know, we basically, whenever it came to a decision on our API, it's like, what would Ember do? You know, like that was our question we would ask ourselves is that was just the easiest thing to do? We gave in, we just did what Ember would tell us to do. And they would fight against it. And it's not that, you know, that can't work. Ember is like pretty flexible. It has the serializer, the adapter, all that stuff. They can make it work. They lost time in it. There's actually a really random bug in Ember that if we had just followed the conventions, then we would have been fine. The bug wouldn't have bit us, but it didn't, Rob actually knows a lot about it. It has to do with capital case properties. But anyway, and so they adopted Ember, but they just weren't as moving as fast as us with it. Mostly because they were fighting against some of its conventions. And so, you know, we've been going a while now. We've had two releases. This is kind of how we started, right? We had a little bit of Ember code, but it was really dominated by our old code. You know, the old code really outweighed the new code. But after a while, we started having more and more of our app rewritten in Ember. And the old code was actually starting to be the much less valuable screens. So we all have screens in our application that just aren't valuable. You have to have them. The user has to have somewhere to go and change to their password. You need to, you know, have those check boxes to do random things. Gmail needs a place for someone to turn on their vacation responder. But those aren't like high value screens. You're not gonna rewrite those on a whim just for the hell of it. And so we wanna get our users using Ember. We wanna keep them in the Ember app all the time because we really want that, you know, front end JavaScript application experience. But we don't wanna rewrite all those low value screens. And so how do we do that? What we ended up doing was putting our old code inside of our Ember code. And this was really straightforward. We just embedded the old app in an iFrame. Like dead simple, right? You just iFrame it. And then all the old screens in our application would have some, you know, code that would run when you were done on that screen, right? There was like a submit button. And then usually what our old app did was redirect you. And so all we did was we changed all the redirects in the old application to redirect to this one screen that would then send a post message up to our Ember application to signal, hey, I'm done inside this application. And then the Ember app would know what to do at that point. And it was really simple. We just used like a mix-in that can control the iFrame and put on the listener for the post message. And then the Ember application was actually smart enough to know you were in this route because we used the router to define all the locations of the old application. And that's how we would know what iFrame to put on the screen. And that was smart enough, like in the deactivate hook of that route, we could refresh data that they might have edited in the old application. We could go get that from the new API so the Ember data store was all up to date. So it was just really simple. And it worked really well. And what it allowed us to do was take our old crappy looking application and rewrite it. Now it's a new, modern, beautiful looking Ember app. If I had like, if I could change the size of the screen, it does like mobile responsive, it's great. We love it. Our customers loved it too. For them it was like Christmas. They got this like, what they thought was a brand new application. Trick was on them, what they didn't know was they were running most of that code for years. All we did was just adjust the templates in the CSS. All the business logic was in the routes and the controllers and in the models. And so we really got to pull a fast one on our users. And so we had finally reached our goal. We had rewritten, especially to our users, our entire application. So meanwhile the other team, they're still waiting on that new software. I'm just gonna leave that one up there for a second. And so this is actually pretty recently that we released that new version. And it got to a point in our company where we're having some issues. We decided the experiment has gone long enough. We need to kind of recombine our teams into some of the engineers to get back together. The sales teams needed help, stuff like that. And so to look back and reflect on what happened, why the signage team, the other team, they're all really smart. They're all really talented people. Why, they didn't set out to fail. And they didn't fail. They just didn't do as good as we did. And I think it really comes down to fear. They were really afraid of their old code. They would rather go nuclear and throw away all that old code than allow it to give value to their customers while they incrementally add value. And so I saw this tweet and I thought it really applied. And so this is the only slide I'm actually gonna read. Either you're swimming in technical debt or you're just too early or too unsuccessful to have accumulated it. And that really strikes a chord with me. I treat my technical debt as my success. And we could've declared bankruptcy and gotten rid of all our technical debt at once, but instead we made a savings plan. And Ember was part of that savings plan. We made a savings plan, we rewrote our application, piecemeal, we delivered new value to our customers and we paid off our debt. And so Ember builds itself as a framework for creating ambitious web applications, but I think it's really a framework for ambitious projects. And an ambitious project doesn't mean it's a Greenfield project. It doesn't mean it's a Big Bang rewrite. To me, an ambitious project is something that's gonna last the long term. We've been building on this code base for 10 years now and I'm pretty sure we're gonna be building on it for another 10 years and I'm pretty hopeful that Ember's gonna be part of that strategy. Ember's conventions really grow with you. And that's something that we've really found is that opinions and flexibility, they're not correlated. And that's a common issue in contention in the JavaScript framework wars. My son likes to build. Here he is building with no conventions. He's working with Play-Doh or my wife makes it, it's just regular dough. And he builds really cool things. He makes pizzas and pies and it's great. But when he builds with Legos, he builds really bigger things because Legos have strong conventions. They click together and he can, even though he's not a talented architect, he can build some pretty cool things. Now imagine when he gets better at building things, those conventions really will scale with him. He can take those same concepts that he uses to build with his Legos right now and build some really amazing things. And the other way doesn't really go the same way. If you don't have those conventions, you really start to break down as you approach the bigger scale. And that's kind of what we saw is our team invested in Ember so early and we just kind of totally gave into it. And we did it piecemeal so we could continue giving value to our customers as we were just really able to take off. And the other team, they're getting there. They just adopted it later and they're a little bit behind us. So that's how Ember affected our two teams. I want to say thanks for coming to hear me talk. So one last thing, I'm really lucky to be the last talk before happy hour. And so I want to be the first one to officially give Robert Jackson a beer. And so Robert, if you're here, I got a beer for you. So this guy has helped me so much in rewriting my application, helping me figure out really bad bugs. It is cold. So have a good happy hour everyone. Thanks for coming to hear me talk. Cheers.