You Do Have Time to Build it Twice


If you don’t have time to build it right, when will you have time to build it twice? In hyper growth startups the old adage breaks down. You get an expanding time horizon – IF you can get it shipped. An imperfect feature next week beats the perfect feature 2 months from now. Your code won’t matter if you’re dead. I didn’t believe this until I saw it myself. A startup on the cusp of hockeystick hired me to rewrite their jQuery app in React. Their tech proved the idea then became a burden. Over the next year we rewrote the whole app from scratch, grew a team of React experts, created a codebase that’s a joy to work with, and got the company to a $100,000,000 Series B. All because the early engineers knew that if the crappy version works out, there’s going to be time and resources to fix it later. This talk is about what I’ve learned while rewriting an app with users banging down the door.



Hey, everyone. I'm Suez. I'm a software engineer, author, and you can tell I'm legit because there's a big screen behind me. So today I want to talk to you about software rewrites. Who has seen this quote before? If you don't have time to build it right, when will you ever have time to build it twice? And I couldn't find an attribution for this quote because so many people have said it. And what I want to tell you today is that you will have time to build it twice later. Because later is the magical time when everything can happen because, at least in a growing company that's doing really well, later also comes with more money, bigger team, more experience, better understanding of your problem. And just later is this magical, magical time. So the story I want to tell you about is how we rewrote a jQuery app in like 2020 from jQuery to React. Full rewrite, we went from scratch. And while we were doing that, we not only didn't slow down team velocity, we actually grew the company like four or five X and got a $100 million Series B round that was announced on the famous NASDAQ screen, which, by the way, doesn't happen just for IPOs. If you know the right people, you can just pay them $100 and you're on there. So I know, I know, I know. I said jQuery and who here has used jQuery in the last, who remembers using jQuery? Okay, okay. Who has used jQuery in 2020, right before the pandemic? Okay, we have three hands. Nice. So I know jQuery is bad, but it's actually still super popular. This is what I tweeted right after Swix, Sean Wang, gave a talk at React.on in San Francisco a couple of months ago. It turns out that 84% of production jQuery is, no, of production JavaScript is still jQuery. And he has this nice graph which, okay, cool, you can see it. If you look at the graph, there's like jQuery 84%, then you have jQuery migrating, I don't know what even that is, and then React is at like 8% of production JavaScript. However, that still means you're at the right conference because React won because none of the other frameworks are on the graph. So at owning 8% of the web, React has won the framework wars, yes, amazing. The other objection you might have to rewrites and starting from scratch is if you've ever read this blog post that came out in 2020, no, sorry, not in 2020, in the year 2000 back when blogs were still popular, this Jolon Software guy who later went on to make Stack Overflow and a bunch of other things wrote a really cool article called Things You Should Never Do. And he essentially makes the, makes, explains why we're not all using Netscape right now. Who remembers Netscape? Okay. Who has actually used Netscape? Nice. Okay, so there's a couple of you. So he makes the argument that Netscape was winning the browser wars until they decided, you know what, Netscape 4 kind of sucks, we're going to write Netscape 5 from scratch, and then IE came in and ate their lunch. So the story about the jQuery to React rewrite. When I joined the company was like June 2020, and they had this little app. Will it play? It's playing. Okay. So this is a jQuery app. It's recorded in mobile mode because that was all that there was. If you open this on a full screen, it would still look just as wide as it looks right now. And this was about maybe 100,000, 200,000 lines of jQuery code. Nobody exactly knew where any of the functions were. If you tried to move anything, it would basically blow up in your face. It was doing all of the best jQuery stuff. Global variables, magic mixins that just create new code, and a lot of it was working on the front end. And actually, here's the super funny part. When I came into the company, I was like, okay, we got a rewrite, we're going to make a React-based SPA, no server-side rendering, et cetera. Now server-side rendering is popular and all of this was actually rendered on the server because that's how you use jQuery. You take express, you spit out a bunch of HTML, then you add global jQuery variables and functions and it works, kind of. This is what we have now. It's a little better designed. I think it looks better. There's some loading spinners. We're actually using React query which solved a lot of our problems. This was one of the nice parts. And the other than looking better, it also has more conversions. Users are happier, our NPS scores, that's the net promoter score about how much users enjoy your product actually went up. And the point I'm trying to make here is that we didn't just rewrite the app from scratch, we also used everything that we learned to improve the product itself. And the rewrite was what gave us the ability to rewrite. And that's because writing software is kind of like kicking a can. You know, when you're walking, it's a nice Sunday, the sun is shining and you're walking down the street and there's a can. And obviously, you walk over and you kick the can. And then you keep walking and the can bounces around and goes to the other side and you kick it from this side and you're kind of like going where the can is going, right? And that's kind of how software works as well. Software is all about playful exploration and discovery of your problem space, kind of like kicking a can. You know, okay, I have this little problem and I'm going to solve it. You kick the can a little further down the road. Then you go where the software takes you and you're like, okay, I now know better. I have to try to kick it more into that direction. So that's kind of what our rewrite was all about. We were changing things, we were updating, getting feedback from users and that's the important part because when you have bad code, the level of effort it takes to make a change goes up exponentially, right? You're usually building the first version of a crappy app. It's super easy, you can do it overnight, you can do it like a very first prototype, you can do overnight if you're like all of you amazing people. I can't, I'm old. So you make the first version and super fast and you get it onto the market. But if you took the time to build a good version and you were, you tried to follow all the best practices, all of the textbook advice, it would take you a really long time to build. It would take, it would be harder to get started. So that's the good code curve, it's way hard to get started but then once you have it, it's easier to keep going and to make improvements because, especially with React, one of my favorite things about React comparing the jQuery code to the React code was that with jQuery I don't want to touch anything. If you move a function to a different file you have no idea what's going to break. With React it's like you can just jump in, grab a function and because it, grab a component function because it's all self-contained and just relying on props and all of that, you can just move it somewhere else and VS Code fixes your imports and everything works great. So you get a lot of that flexibility which then once you have a lot of code and more engineers it makes it easier to work together. But that space between, that space in the graphs where the bad code is fast to get started and then gets really hard and the good code is slow to get started and then gets really easy, that is your, that is what I would call your opportunity space. If you, crap, how was I going to explain this? So that is your opportunity space is there. That's where you can get a lot of feedback very quickly and start using it in a rewrite that lets you improve and get better code and what you're hoping to achieve is that before those, before the two lines intersect if your rewrite or if your refactor or improvements aren't ready, you die. And that's the fun part of working at startups. It's like either we get it done or it doesn't actually matter because nobody cares about a startup whose code doesn't, isn't used anymore. I could use a really punchy example there. But anyway, how do you approach a rewrite? I'm sure, actually who here has advocated to stop working on features and go rewrite the code? Yes. Who has an engineering backlog that you never get to? Exactly. And the reason that happens is because the business people aren't as stupid as you might think. You don't have time to stop the company and just go work on tech debt because that is how Netscape died. It wasn't because they were rewriting, it's because they said we're just not going to have a new version of the software for three years while we do this. And that doesn't work. What does work is something called the strangler pattern or you can, I've also heard it called the ship of TCS rewrite where you slowly replace your code piece by piece until there's nothing of your old code left. I don't actually remember why it's called the strangler pattern. It's not like about grabbing the old code and choking it until it goes away. It has a much, it has a nicer origin story. I think it's something about vines in the jungle. So there's kind of two ways that you can approach this. Whenever you build, whenever you're building a new feature or adding functionality to your app, you can either decide you're going to go top down where you replace entire pages with new functionality or you can go bottom up where you create something like, in my company we call it a React island where you essentially build a G query like plug in that renders React in a div. That actually works really well. But the, if you're rewriting a whole app, if you have time to rewrite the whole app, the page by page approach is I think a lot easier. So what we did was that for about maybe a year or six months, something like that, we had a kind of janky experience. You would, users would use the G query app, click a random button and end up in the beautiful redesigned React app. Then they would click another button and be back in jQuery land. Which kind of looks, you know, as a user it's like what the hell is going on here? I think the biggest example of this in practice that I've seen was my bank where the login page was amazing and beautiful and then you click log in and you're in this janky old app that looks like it was designed ten years ago. But I feel like as people, as users, we're kind of used to these redesigns. So as long as the designers do a really good job and they keep that continuity of design or whatever you want to call it, the users don't actually care. They understand, yes, you know, a new BMW comes out every year and has bigger and bigger and bigger grills, but it's still a BMW. You recognize that it's a BMW. You know it's a car. You know how to drive it. And the main things are the same but the small things keep changing. And the page by page approach also gives you an excuse or an opportunity to do product innovation. You're not just fixing the code, you're also fixing how the product works. You're starting with a skateboard, then you build a scooter, you turn it into a bike, then you have a motorcycle, and in the end you have an amazing BMW or Porsche or just this cool car that everyone is going to love. And the rewrite actually, in my experience, product managers love it if you do it this way because they also hate dealing with legacy stuff. They would love to just have new features and they come to you with this great idea and you say, yeah, you know what? That's going to be really easy. We can just build it because we're throwing away all the old code and we're doing it in the new style that's faster to work with so we don't have to deal with everything else because, let me tell you, at an older company we once had, we were dragging along about five years of pricing model iteration and the PM came to me and was like, hey, can we add this new type of charging users? And I was like, yes, we can charge them a different way. It's going to take three months to add that. And we did unfortunately decide to add that and one lesson I learned is don't ever innovate on your pricing scheme. People just want to pay by month and they don't care about anything else. It's just, it's not worth it. But do innovate on the product. Do innovate on what the users are actually using. Now at the end of the day, we spent an entire year rewriting the app from scratch. Right now if you go to our thing, if you click certain buttons you still go back to the old jQuery world because we couldn't update the backend. And the question might be, was it worth to, was all of this effort worth it? Was it worth putting in the effort to rewrite the jQuery app into React? And honestly, it kind of was. When we raised the round, the $100 million round, it was, our effort was essentially worth like half a million dollars per employee. But the valuation went up to about three million. So you know, it can be worth it if your company is on the right trajectory. And please listen to the last line of my tweet over there. You're worth a lot of money to your employers. Go negotiate that shit and get paid. And actually, I'm right now writing a book based on this experience. It's going to go into a lot more depth on how refactors and rewrites work. And if you want to get notified when it's ready, that's the QR code for you. And that's actually all I had to say. Great job, man. Thank you. Oh, there's lines on the floor. So Swissac, refreshing talk. I was thinking of an experience I had when I was interviewing at a company that was now at the time where they were deciding to build their first prototype. And like, are we going to jQuery, bootstrap it, or are we going to properly build it? And for me, that was a hard decision because I didn't want to go to them if they decided to go to bootstrap jQuery world. I'm a bit of a snob, maybe. But what made you decide to actually want to do it? So that's actually a really funny story because when the head of engineering pitched me to come rewrite their jQuery app to React, he said, we need to do this because it's impossible to hire engineers to come work on jQuery. Nobody wants to do this. And yeah, that's why I went. Because it was like, yes, I get to design the entire React experience, the framework, set the future of the company. And I think it's worked out so far. So you joined when the React, the jQuery bit was already done in production. Ah, OK. Yeah, so I joined when that was already ready. It was the best they knew at the time. It was the best that they, it was the fastest way for them to build it. And then they were like, we need a React expert to come in and fix it for us. And you're the guy to do it. Nice. Well, good experience. So we're going to jump into the questions from the audience. Question from Anonymous. Is the app still mobile first? Well, I think you showed it, right? Yeah, so the app, right, so we're using a CSS in components framework, like a CSS in JS framework called Team UI that's super responsive. So the app is mobile first, but it works everywhere and automatically adapts. And that was one of the reasons we rewrote was because we could make it easier to do that with modern tooling. But then do you still see in your statistics that maybe 9 out of 10 people still come on mobile because they're used to accessing the product from mobile? Yeah, and actually that slowly went away. As the app started working better on browsers, people started coming on more on laptops. And probably also new users that didn't know that there was no desktop experience. Yeah. Nice. How do you protect yourself from scope creep when it comes to production, product innovation while rewriting? Right. So scope creep is mostly, honestly, the best solution I found to scope creep is to join a company that's growing really fast and has users banging down the door. Because then everyone is on board with, okay, let's just get this out quickly. We don't have time to make it perfect because we are literally losing users by not being able to ship. So that makes it really easy to tell your PMs, yo, we don't have time for this shit. Yeah. Got to get going. And then in the legacy app, were there any tests written or you just had to hope that what you rewrote was the same? There were some tests in the old app. The benefit of our rewrite was that the PMs also wanted to improve the product. So all of the old tests just didn't actually apply anymore because the features were different. So yeah, it wasn't like a rewrite just from a technical perspective. It was also an app reimagining and improvement. Yeah, okay. It wasn't a one-on-one rewrite. Yeah, it wasn't a one-on-one rewrite. So it's like, you know, you're turning a submarine into a boat. Not a lot of tests still apply. Yeah. Maybe one or two tests that this back-end call is made. Yeah, exactly. But that's it. Yeah. Okay. Okay. Then was there any server-side functionality? If yes, what framework or library did you use? There was a lot of server-side functionality. Because this was an Express app that was rendering HTML and then jQuery was taking over. So they basically had hydration before we knew about hydration. So all of the back-end stayed. We turned it into API calls and we're now slowly rewriting the back-end as well. It's written in Express, Node.js with plain JavaScript. Okay. So that sounds like some solid software engineering on the right. Yeah. The back-end, they did a great job. All right. So that's all the time we have for SwissEgg. So I'm going to thank you. Good to have you. And so a big round of applause, of course.
21 min
17 Jun, 2022

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic