The Tale of Two Teams
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Tiley, Ray
So lets talk about two teams, both with old, messy, outdated code bases. One team chooses a framework, refactors behind the scenes, ships new features and one day have a shiny, modern code base. The other rewrites it all, from scratch, with sprinkles of JavaScript. How did these two teams fare? In this talk we'll find out. Spoiler alert... both teams are happily using Ember today.
 Tell to 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. Have you 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 are, we're actively maintained right now, predate Git. They're at least 10 years old. I have no idea when they came into fruition 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, it's 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. And 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. Save 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 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 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.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 how do we, 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's 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. We 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're 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 when people ask me all about when you say this is continuity. How does 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 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. 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 Cablecast 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 going to 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 with the customer, I'm not going to say 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. 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 like 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 start with really high fidelity mockups. 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. And the problem there is it's not as bad as transitioning from the Photoshop, 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 related 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, 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. So 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 how valuable Ember CLI's tooling was in getting our product shipped. So when we last checked in, here we were. The R team had shipped some new Ember code. 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 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 going to 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. We were stepping away from our incremental rewrite. 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 through 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 push it back together. And 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 a way better way to organize my jQuery projects. And then I come back to that old project I have to work on again. And man, I need to redo all this. And I need to upgrade grunt because it's not running anymore because NPM installed a different version this time. So there is just a lot of friction from getting on and off their project. Because they had 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. They're doing their own reading. They see the Tomster. This seems like a good idea. So they switched to Ember. But they don't go all in. And so 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, we basically, whenever it came to a decision on our APIs, like what would Ember do? That was our question we would ask ourselves. Because 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 that can't work. Ember is pretty flexible. It has the serializer, the adapter, all that stuff. They can make it work. But 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 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. Especially because they were fighting against some of its conventions. And so 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. 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. They need to have those checkboxes to do random things. Gmail needs a place for someone to turn on their vacation responder. But those aren't high value screens. You're not going to rewrite those on a whim just for the hell of it. And so we want to get our users using Ember. We want to keep them in the Ember app all the time. Because we really want that front end JavaScript application experience. But we don't want to 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? Just iframe it. And then all the old screens in our application would have some 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 somewhere. And so what 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, like, 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 APIs 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 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 know is 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 Ember in the models. And so we really got to pull a fast one on our users. So we had finally reached our goal. We had rewritten, especially to our users, our entire application. Yes. So meanwhile, the other team, they're still waiting on that new software. I'm just going to leave that one up there for a second. And so this was actually pretty recently that we released that new version. And it got to a point in our company that we're having some issues. We decided, you know, the experiment has gone long enough. We need to kind of re-combine our teams into, you know, some of the engineers to, you know, get back together. The sales teams need to 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, like, slide I'm actually going to 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, you know, we could have declared bankruptcy and gotten rid of all our technical debt at once. 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 is, 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 green field project. It doesn't mean it's a big bang rewrite. To me, an ambitious project is something that's going to last the long term. We've been building on this code base for 10 years now and I'm pretty sure we're going to be building on it for another 10 years. And I'm pretty hopeful that Ember is going to 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 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 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. 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. Thanks for coming to hear me talk. Thanks for coming to hear me talk.
 Tell to 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.  Have you 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 are, we're actively maintained right now, predate Git.  They're at least 10 years old.  I have no idea when they came into fruition 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, it's 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.  And 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.  Save 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 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 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.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 how do we, 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's 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.  We 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're 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 when people ask me all about when you say this is continuity.  How does 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 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.  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 Cablecast 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 going to 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 with the customer,  I'm not going to say 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.  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  like 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 start with really high fidelity mockups.  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.  And the problem there is it's not as bad as transitioning from the Photoshop, 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 related 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, 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.  So 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 how valuable Ember CLI's tooling was in getting our product shipped.  So when we last checked in, here we were.  The R team had shipped some new Ember code.  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 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 going to 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.  We were stepping away from our incremental rewrite.  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 through 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 push it back together.  And 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 a way better way to organize  my jQuery projects.  And then I come back to that old project I have to work on again.  And man, I need to redo all this.  And I need to upgrade grunt because it's not running anymore because NPM installed a different  version this time.  So there is just a lot of friction from getting on and off their project.  Because they had 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.  They're doing their own reading.  They see the Tomster.  This seems like a good idea.  So they switched to Ember.  But they don't go all in.  And so 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, we basically, whenever it came to a decision on our APIs, like what would  Ember do?  That was our question we would ask ourselves.  Because 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 that can't work.  Ember is pretty flexible.  It has the serializer, the adapter, all that stuff.  They can make it work.  But 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 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.  Especially because they were fighting against some of its conventions.  And so 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.  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.  They need to have those checkboxes to do random things.  Gmail needs a place for someone to turn on their vacation responder.  But those aren't high value screens.  You're not going to rewrite those on a whim just for the hell of it.  And so we want to get our users using Ember.  We want to keep them in the Ember app all the time.  Because we really want that front end JavaScript application experience.  But we don't want to 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?  Just iframe it.  And then all the old screens in our application would have some 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 somewhere.  And so what 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, like, 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 APIs 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 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 know is 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 Ember in the models.  And so we really got to pull a fast one on our users.  So we had finally reached our goal.  We had rewritten, especially to our users, our entire application.  Yes.  So meanwhile, the other team, they're still waiting on that new software.  I'm just going to leave that one up there for a second.  And so this was actually pretty recently that we released that new version.  And it got to a point in our company that we're having some issues.  We decided, you know, the experiment has gone long enough.  We need to kind of re-combine our teams into, you know, some of the engineers to, you know,  get back together.  The sales teams need to 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, like, slide I'm actually going to 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, you know, we could have declared bankruptcy and gotten rid of all our technical debt at  once.  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 is, 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 green field project.  It doesn't mean it's a big bang rewrite.  To me, an ambitious project is something that's going to last the long term.  We've been building on this code base for 10 years now and I'm pretty sure we're going  to be building on it for another 10 years.  And I'm pretty hopeful that Ember is going to 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 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 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.  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.  Thanks for coming to hear me talk.  Thanks for coming to hear me talk.
The_Tale_of_Two_Teams_0_623.png The_Tale_of_Two_Teams_624_671.png The_Tale_of_Two_Teams_672_1091.png The_Tale_of_Two_Teams_1092_12227.png The_Tale_of_Two_Teams_12228_13979.png The_Tale_of_Two_Teams_13980_15179.png The_Tale_of_Two_Teams_15180_17771.png The_Tale_of_Two_Teams_17772_17879.png The_Tale_of_Two_Teams_17880_18143.png The_Tale_of_Two_Teams_18144_18455.png The_Tale_of_Two_Teams_18456_21071.png The_Tale_of_Two_Teams_21072_21659.png The_Tale_of_Two_Teams_21660_23051.png The_Tale_of_Two_Teams_23052_26915.png The_Tale_of_Two_Teams_26916_27215.png The_Tale_of_Two_Teams_27216_27335.png The_Tale_of_Two_Teams_27336_27755.png The_Tale_of_Two_Teams_27756_29495.png The_Tale_of_Two_Teams_29496_29747.png The_Tale_of_Two_Teams_29748_35303.png The_Tale_of_Two_Teams_35304_35375.png The_Tale_of_Two_Teams_35376_35519.png The_Tale_of_Two_Teams_35520_35627.png The_Tale_of_Two_Teams_35628_35819.png The_Tale_of_Two_Teams_35820_35867.png The_Tale_of_Two_Teams_35868_36095.png The_Tale_of_Two_Teams_36096_36251.png The_Tale_of_Two_Teams_36252_36299.png The_Tale_of_Two_Teams_36300_36347.png The_Tale_of_Two_Teams_36348_36395.png The_Tale_of_Two_Teams_36396_36443.png The_Tale_of_Two_Teams_36444_37043.png The_Tale_of_Two_Teams_37044_37103.png The_Tale_of_Two_Teams_37104_39419.png The_Tale_of_Two_Teams_39420_39539.png The_Tale_of_Two_Teams_39540_40115.png The_Tale_of_Two_Teams_40116_40211.png The_Tale_of_Two_Teams_40212_41363.png The_Tale_of_Two_Teams_41364_43139.png The_Tale_of_Two_Teams_43140_45299.png The_Tale_of_Two_Teams_45300_45347.png The_Tale_of_Two_Teams_45348_45623.png The_Tale_of_Two_Teams_45624_45865.png