You Do Have Time to Build it Twice

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? I couldn't find an attribution for this quote because so many people have said it. 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.

The story I want to tell you about is how we rewrote a jQuery app, yes, a jQuery app in like 2020, from jQuery to React, full rewrite, we went from scratch, and while we were doing 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 a hundred bucks 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, Shawn Wang gave a talk at React.com in San Francisco a couple months ago. It turns out that 84% 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, Migrate, and 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 1, 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 rewrite 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 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. 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 frontend. And actually, here's the super funny part. When I came into the company, I was like, okay, we got to 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. That 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 company, 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.

So, 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.

You're usually building the first version of a crappy app is super easy. You can do it overnight, you can do it like a very first prototype, you can do overnight you're like, all of you amazing people. I can't, I'm old. So you make the first version, and it's super fast, and you get it onto the market. But if you took the time to build a good version and 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 be harder to get started.

So that's the good code curve, it's way hard to get started, but once you have it, it's easier to keep going and to make improvements, because like, 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, you can just jump in, grab a function, and because it's all self-contained and just relying on props and all of that, you can just move it somewhere else and VSCode 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 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 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 isn't used anymore. I could use a really punchy example there. But anyway, how do you approach a rewrite, right? 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 Tethius 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'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 GQuery-like plug-in that renders React in a div.

That actually works really well. 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. What we did was that for about maybe a year or six months, something like that, we had a kind of janky experience. Users would use the GQuery app, click a random button, and end up in the beautiful, redesigned React app, and then they would click another button and be back in GQuery land, which kind of looks terrible. 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 login, and you're in this janky old app that looks like it was designed 10 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 grilles, 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, like, we were dragging along about five years of product, 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 the prep, 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 it? 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, like the hundred million dollar round, it was, our effort was essentially worth half a million dollars per employee, but the valuation went up to about three million. 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. Yeah. Oh, there's lines on the floor. So, Swissec, 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 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 the 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? Okay. Yeah. So I joined when that was already ready. It was the best they knew at the time. It was the best that they was the fastest way for them to build it. Yeah. And then they're 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? I think you showed it, right? Yeah. Right? So we're using a, like a CSS in components framework. Like I said, CSS and 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 like one of the reasons we rewrote was because it would, we could make it easier to do that with modern tooling. But then do you still see in your statistics that like maybe nine out of 10 people still come on mobile because they're used to accessing the product from mobile. 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. 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.

Yeah. 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're literally losing users by not being able to ship. That makes it really easy to tell your PMs, yo, we don't have time for this shit. Yeah, gotta 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. 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, this backend call is made, but that's it. Yeah, exactly.

Okay. And then, was there any server-side functionality? And 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 had like, they basically had hydration before we knew about hydration. So all of the backend stayed. We turned it into API calls and we're now slowly rewriting the backend as well. It's written in Express, Node.js with plain JavaScript.

Okay, well, it sounds like some solid software engineering. Yep, the backend, they did a great job. Alright, so, that's all the time we have for SwissEx, so I'm going to thank you. Good to have you.