Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor — a choice that many projects face as they grow. It’s is a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- 615 – Kent Beck on Tidy First
- 638 – Nick Tune and Jean-Georges Perrin on Architecture Modernization
- 625 – Jonathan Schneider on Automated Refactoring with Openrewrite
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Sam Taggart 00:00:19 This is Sam Taggart for SE Radio. Yvette Ordog is the creator of a gamified DevOps training tool called Lean Poker. She has over 15 years of experience in software development and leadership. And today we are going to talk about rewrite versus refactor. We’ve talked about similar subjects on the podcast previously in Episode 615, Tidy First, 638 Architecture Modernization and 625 Automated Refactoring. Welcome Yvette.
Ivett Ördög 00:00:44 Hi.
Sam Taggart 00:00:46 So you have some unconventional views around the refactor versus rewrite debate. Before we get to that though, how do we get to this decision point where we have to decide whether to rewrite or refactor?
Ivett Ördög 00:00:58 I think that one of the core issues with software development is that we tend to have these emergent systems and as we develop them over time, they get so complex that we lose track of it and it becomes really hard to maintain and there are a lot of ways we can avoid that. The problem is that those ways are expensive and I think this is the controversial part where I’m saying that yes you can actually keep a system clean enough that you can always move fast, but that effort of keeping the code base clean is a non-zero effort, which is too expensive for small companies, which leads to the consequence of almost every single successful company having a code base that is considered legacy or considered something that most engineers don’t really like touching.
Sam Taggart 00:01:53 Yeah, that was going to be my next question. So how does this relate to the term legacy code? What exactly does that mean to you?
Ivett Ördög 00:02:00 Yeah, so I really like the definition of Michael Federer’s that any code that doesn’t have tests is legacy code. I feel like it’s not complete. In the context of his book, that definition absolutely makes sense, but I have seen code bases that had tests and were still really hard to maintain or even add features to. So I think that the better way of looking at it is basically legacy code is code that I feel uncomfortable working with and that is kind of a more general definition for me also because like I have seen code bases that didn’t have tests and I was still comfortable working in it.
Sam Taggart 00:02:42 Yeah. So can you dive into that a little bit? Can you give some examples of some code bases that had tests but were hard to maintain?
Ivett Ördög 00:02:48 Yeah, so the code base that we struggled with was a PHP legacy code base and part of the reason it was really hard to work with is because it was started by a bunch of junior engineers without any adult author or oversight. So they basically ended up creating this really hard to maintain code base where logic was intermixed with templating and with database interactions and everything. And over time we started adding tests to it. But honestly like when you have that level of complexity just mixed up, even adding those tests can only help you so far, right? You still need to refactor a lot and sometimes even if you do refactor you might end up with like a system that is logically insufficient in the sense of, so the specifically example I want to give is an import process that we had and that import process was meant to process a CSV file and then move all the data from the CSV file into the database. Unfortunately the way this was implemented is to move everything field by field, not even line by line. Like every single field update was a separate SQL query with lots of round trips, to the database. And solving that issue is a bit more than refactoring, right? Because we do need to change the behavior of the system. And how do you do that without actually writing the whole system? That was the question that we had to answer.
Sam Taggart 00:04:24 In that case, I would imagine the test may have gotten in your way as well because we’d have to rewrite the test to change the system behavior.
Ivett Ördög 00:04:30 Yes. Luckily, we didn’t really have unit tests. I say luckily exactly because of the reason what you said, it would be hard to not break those unit tests while you are doing something like this. We had more like end-to-end tests and those were a bit more reliable because we didn’t have to like it didn’t touch the internal logic of the system, it was just actually importing a CSV file and then checking the database. So that was helpful. But having said that, we did need to seriously rethink the system and have a completely different approach for loading that data into the database.
Sam Taggart 00:05:10 You also mentioned that you’ve encountered some code that did not have tests but was easy to refactor. What made that easy to refactor?
Ivett Ördög 00:05:17 So one system that was fairly easy to refactor actually it was a system that had a backend in the front end. And interestingly the front end was horrible and really hard to work with because it was just really quickly, it was actually my own system I wrote were a few days because I had a deadline coming up so I just rushed it all together. So the front end was really hard to work with, but the backend was actually fairly clean and also it didn’t have any tests. And the reason it was really easy to work with backend was because even though it didn’t have tests, I kind of had a dashboard as part of the front end that showed everything. So when I reloaded that page, I immediately could tell if every single part of the system is working because that single page was kind of a test. Of course it required me to know what to expect on that page, right? But it was enough for me to have a basic level of feedback that is enough for me to work with.
Sam Taggart 00:06:17 Okay. Another term that gets thrown around is technical debt. How does legacy code relate to the term technical debt?
Ivett Ördög 00:06:25 That’s a really interesting concept and I think some people don’t like this term because it kind of implies that like has this parallel with financial debt and businesses are very happy to go into debt, right? That’s all we have with investments. Investments are about going into debt. So businesspeople are usually very comfortable with that concept and because of that it becomes a conscious decision if we want to take on debt, right? And I think a lot of engineers don’t like that because that means that they can be pushed to take on debt which they might not want to be pushed into. At the same time, I think it’s still a really valid concept. And actually it’s even better than financial debt because think about the worst-case scenario, which is actually the typical case scenario for a startup. You start building something and it either works or it flops.
Ivett Ördög 00:07:25 You might have a project that seems like a good idea on paper, you build it, you ship it, and then no one uses it. Which one would you rather have financial debt or technical debt? Because financial debt, you still have to pay, the technical debt that’s really easy to pay at this point because you can just delete the code, right? And now you are whole debt is gone. So as a startup often taking on technical debt in this fashion, like making a conscious decision of deferring architectural decisions to later and deferring refactoring to later is a smart decision as long as I’m still trying to race towards a point where I can validate my idea.
Sam Taggart 00:08:12 Do you find that some teams unintentionally take on technical debt? Is that a thing?
Ivett Ördög 00:08:19 I think it is a thing and I think that what I would definitely advocate for is being smart about technical debt, right? You don’t want to take it on unintentionally. You want to make a calculated decision when you’re taking on technical debt. You need to be aware that you can run into a situation where you bankrupt yourself because of technical debt. So a minute ago I talked about being able to delete the code and then the technical debt is gone. That’s true. But at the same time, if your product is successful then you have a different problem, then you have technical debt that you consciously or unconsciously have taken on and now you need to fix that because over time it will become really, really hard to get out of it because it’s exponential. Just with normal monitored debt, technical debt can become an exponential burden.
Sam Taggart 00:09:18 Can you give some specific examples of where you see that happen?
Ivett Ördög 00:09:21 Some of the projects that I have worked on, we are basically every single time got ourselves out of that technical debt, right? But there were projects again going back to the PHB system that had the import that was part of a larger system and there the amount of technical debt that was already around meant that the team couldn’t deploy a new version of the software for over a year. And when they did, they had to roll it back again and then another half a year went by just fixing bugs, not even adding new features and they had to draw back again. So this level of technical debt is already catastrophic, right? And if it wasn’t for two very talented engineers who later became my bosses coming on board and fixing that system or starting to fix that system, that company could have come bankrupt.
Sam Taggart 00:10:13 What are the biggest challenges that companies face dealing with legacy code and technical debt and how does that differ based on the scale of the organization?
Ivett Ördög 00:10:23 I think that the scale of the organization is very important in this respect because if you are a small organization, you can’t really gather enough technical debt so that it causes you a problem with any small scale system you can always get out of the hole you dig yourself into in a couple of weeks When it becomes interesting is with large scale systems where there are a lot of interdependencies and more importantly a lot of communication overhead between teams. And this is kind of leading on to a slightly different topic, which is a topic of microservices because I feel like part of the appeal of microservices is that it’s kind of an architectural style that makes sure that all of your subsystems remain below that threshold where you can create a huge issue with technical debt and each of your subsystems can have some amount of debt, but you can always fix it and you can always decide to replace one part of the whole system with a drop in replacement, unlike with a large monolith where everything you touch is going to move everything else.
Sam Taggart 00:11:36 Do you feel that microservices addresses that problem successfully.
Ivett Ördög 00:11:40 If done well? Yes. And that’s also something that’s important. When people talk about microservices, they often talk about microservices as just a way of having multiple services that are somehow interconnected. And I don’t think that’s the right way to look at it in my view. And as far as I understand what Dave Farley talks about in his view as well, that these systems are meant to be decoupled and independent of each other and that the boundaries between them should be very well defined and minimal.
Sam Taggart 00:12:13 You mentioned that as an organization scale, the problems change. Where is that line? Is there a line? Is it when you split to multiple teams or is there some other line that generally markets where you need to change your approach?
Ivett Ördög 00:12:27 Yeah, I mean I only saw one company go through this shift, right? Most of the companies that I worked with were either before the shift or after, and I only one sample to tell to extrapolate from. So I feel like I can give you a guess, which is I think it’s around about 50 engineers where this becomes a problem. But of course it will depend on the variety of factors.
Sam Taggart 00:12:53 What is the design stamina hypothesis and how does the graph change when considering rewrite versus refactor?
Ivett Ördög 00:13:00 Ooh, yeah, that’s a really interesting concept. So this is coming from Martin Fuller. He had this hypothesis where he says if we start with good design, that means that we are going to start off slowly and then as we progress because our design is good, we speed up exponentially, right? So once we have done a bunch of work, then we have all these building blocks that we can build together.
Sam Taggart 00:13:27 I’ve seen this described as a graph. Can you describe the x and y axis just for people who haven’t seen it?
Ivett Ördög 00:13:32 Yeah. Okay. So let’s imagine this graph on the X axis, you have the time that it took you to implement the number of features and on the Y axis the number of features that you have implemented. Okay? So when we go through time, what you would see is as you add new features, this graph is slowly growing, right? And the question is how fast is this graph growing? Is it going to grow slow or fast? And the design hypothesis stipulates that if you do not design, then over time at the beginning you will really quickly add features because you don’t have to worry about design, you are just piling on features onto a system and then over time this is going to slow down because you haven’t done it good design. So you will have all this technical debt slowing you down. That’s one option.
Ivett Ördög 00:14:23 The other option is you do good design and, in the beginning, you don’t even implement features or only implement a few features. And as you progress, this good design that you have done upfront will slowly hop, you move faster and then suddenly you are on a really steep curve where you can add lots of features in a small amount of time. Now the tricky part is that this hypothesis says that at the beginning doing design will result in less features over time and after a certain period, which is the design payoff line, after that point the design will pay off and you will move much faster with design. So that’s the design summary hypothesis. Note that this actually only assumes two possible options. You either do a lot of design upfront or you do no design. There is no middle ground here yet.
Sam Taggart 00:15:22 And also, if I remember correctly, that exact point is indeterminate at where the two graphs pass, right? No one knows exactly when one passes the other.
Ivett Ördög 00:15:30 Yeah, that’s definitely true. We might have a guess where it crosses. And if you ask engineers, a lot of engineers are going to give you very different estimates on where that line is.
Sam Taggart 00:15:43 Yeah, I’ve heard JB Rains Berger talk about this and I believe he said something like, if you’re before the line then it makes sense to not do the design. And if you’re after the line then it makes sense to do the design. But the problem is no one knows exactly where the line is, and which side your project’s going to fall on.
Ivett Ördög 00:15:57 And also if your project fails, you are almost definitely going to be before the payoff line. But if it’s successful you’re almost definitely going to go beyond that line because if you are successful, you are going to start adding more features. So the big question is when to choose what and maybe is there a middle ground?
Sam Taggart 00:16:18 Great. So let’s move into the rewrite versus refactor debate and maybe we’ll revisit that graph again. Can you define rewrite and refactor and talk about the difference between the two approaches?
Ivett Ördög 00:16:30 Rewrite would be something where you just throw away all of the code and you start over from zero. And refactor would imply that you change the system incrementally with just modifying the structure without changing the behavior. And basically in a classic setting or this classic definition of refactor implies that you’re doing it in so small steps and every step of the way you have a working system. So that’s something that you do continuously to clean your code base. Where it becomes interesting is that often people talk about bigger factors where you need to change a bunch of things together in order to get to a more sustainable design. And how do you make sure that you don’t just start doing that refactor, do parts of it and then have to end up living with a hybrid situation. So when I talk about big refactors, I talk about situations where doing part of the refactoring job might actually temporarily make things worse.
Sam Taggart 00:17:37 I’ve always thought of refactoring as limiting risk by taking smaller steps. When you do these larger refactorings, are you then increasing the risk?
Ivett Ördög 00:17:45 In a sense, yes you might be increasing the risk at the same time I feel like if this is done well and in a sustainable way and we can talk about what that way is, this can be a good thing. Having said that, if you can avoid having to do a big refactor, you should. Like my general opinion is that you shouldn’t do a rewrite or refactor unless you absolutely have to. And then the question is when is it that you absolutely have to and what do you do then?
Sam Taggart 00:18:19 Yeah, that is going to be a question and we will revisit that in a minute. Before that though, our rewriting refactors the only two options or is it possible to do like a partial rewrite or something like that?
Ivett Ördög 00:18:31 Yeah, so when I say rewrite, I often think of partial rewrites. And this is also an interesting concept here that you might be tempted to rewrite an entire system but often when you think about it there is one specific part of the system that is bugging you or that is the most painful for you. And thinking about okay, how can I limit the impact circle? Like again I said that don’t rewrite or don’t do big refactor if you can avoid it. But if you can’t avoid it often you don’t have to do it with the whole system. Often, it’s mostly just one part of the system. So yes, partial rewrites are a thing.
Sam Taggart 00:19:13 Alright, let’s go back to that previous question. How do you know when you’ve ended up at the point where you don’t have a choice, but you have to do some large-scale refactoring or rewriting? What are the signs, what can we look for?
Ivett Ördög 00:19:23 Okay. For me some examples that I can give. One example was this import that I previously mentioned. There was no option of refactoring because the logic of how we did the import was fundamentally flawed. You can’t refactor it because that wouldn’t change the behavior. We needed to change the underlying behavior of the system. And then refactoring is out of the question. Another very typical case of you can’t do a refactor is when the platform you are building on is not suitable anymore. So one example that I like bringing here is there is this presentation software called Prezi and the problem Prezi had been they built their whole system in action script and action script was a really trendy thing at the time. But of course since then we know that it basically got killed off because of a bunch of security issues and because iPhone and Apple in general started to block it altogether. So there was no option of refactoring because they just had to move to different platform. And then you can architecture.
Sam Taggart 00:20:37 So an example that might be perhaps switching from one language to another or maybe moving from like maybe a SQL database to a no SQL database or something like that, that would require a bunch of changes?
Ivett Ördög 00:20:50 Yes, there’s definitely options. I would feel that even with a like a database switch, it’s more likely to be like you can still do certain database switches with refactoring. Actually there is even a wonderful book refactoring databases just about that. So you can actually do stuff like that. But yes, when you have a fundamental change either in the behavior of the system or the way it is built that is necessary for you to enable new business capabilities, that’s when you need to rewrite instead of refactor.
Sam Taggart 00:21:24 What other factors should organizations consider when deciding between rewrite and refactor?
Ivett Ördög 00:21:30 The way I would rephrase the question is what are the fundamental required features of a large scale refactor or rewrite? Because I feel like that in general you want to stay on the small scale refactor side, but when it becomes obvious that the system is not your friend here and you are slowing down, I think that most of the time when you consider something like this rewrite or big refactor thing, it usually has to do with a very specific business need that we have. And when you do that, I think there are two very important things to consider. The first thing to consider is how can I make sure that this project is delivering customer value? Something that the user can also feel. This might be something like enabling a new feature that wouldn’t be possible with the existing system or making sure that more customers can be reached because we are opening a new market.
Ivett Ördög 00:22:37 Or maybe the only thing that the user notices is the system is more responsive or easier to use. But in the end, one of the two important things that I usually ask teams when they consider a rewrite is how is this rewrite going to contribute to customer value? The other thing that is important to consider is can we do this incrementally? Can we make sure that it’s not an all or nothing effort? We don’t want to be in a situation where we start a rewrite and then we have to stop it and then suddenly we have a half-finished product and we never get to release it, right? So can we do this rewrite in a way that parts of the rewrite are already used and enjoyed by customers before we finish?
Sam Taggart 00:23:30 You don’t believe in burning the ships, the old analogy of lakes across the sea and then like we burn the ship, so we know we’re not going back.
Ivett Ördög 00:23:37 Yeah, not really, not really. That’s kind of either it comes to software engineering or politics. I don’t believe in revolutions. I believe in incremental improvements.
Sam Taggart 00:23:49 When we talk about incremental, what size increments are we talking? We’re talking really small increments. How large do those increments become before they get too large?
Ivett Ördög 00:23:58 I would say make it as small as you can and at a minimum you should be able to have a releasable and valuable increment every two weeks. If that doesn’t go maybe once a month but don’t go above once a month. If you are above that line, you’re very likely to run into situations where you need to change direction before you actually can release something. But having said that, the smaller the better. I had teams who could release every three days and that’s the best because then every three days you have a validation that you are still in the right direction. Every three days you get to realize if you are in not in the right direction and change direction. So that’s for me the idol is as small as possible.
Sam Taggart 00:24:47 I’m forming an analogy in my head, I want to see if it resonates, but I think of it as like you’re in a pond and you’re like hopping from li pad to lay pad. So you’re like going from like one safe area jumping to the next one or maybe my kid really likes the floors lava and you jump from like one couch to another or something and there’s like all this floating lava that you’re trying to avoid. Does that seem like an adequate analogy of like trying to take those tiny steps just to get to the next safe spot?
Ivett Ördög 00:25:10 I think that’s a wonderful analogy. I haven’t heard that before and I think I’m going to steal this because it’s, it really visually gives a good example of what we are talking about. Like the larger you need to jump, the more likely you are going to break your leg. It’s very obvious. Thank you for this analogy.
Sam Taggart 00:25:31 Yeah. At least in the software world though as you said, if you take us of all a jump and you miss, you can always roll back which floor and lava maybe not if it’s actually real lava.
Ivett Ördög 00:25:41 Yeah , yeah definitely. But you still get wet when you fall into the water, right? So maybe that li pad example is even better where yes, I mean you can fall into the water and it’s not the end of the world but the larger the distance, the more time you need to swim to the next lily pad and it’s going to be painful and then you get out and your vet and you are cold, not pleasant.
Sam Taggart 00:26:05 There’s a lot of dogma out there that says don’t ever do a rewrite. Where did that come from?
Ivett Ördög 00:26:11 Yeah, I think that mainly comes from a lot of companies failing between writes, right? Honestly, I’m lucky enough that every time I tried my hand at the rewrite, I was successful. But that’s probably partly because my first year write was under the guidance of someone who was really good at this. So I immediately learned from the best how to do this well. But before, like if you look back in more in the history of software engineering, there were a lot of companies that failed and there is an argument that part of the reason Netscape failed was their attempt at rewriting a Netscape navigator. There were other factors there that Microsoft actually got sued over. But one of the reasons was definitely that they didn’t deliver new features for a long time, and they basically led themselves fall behind the competition.
Sam Taggart 00:27:08 Why is the idea that we shouldn’t rewrite problematic? Have you seen any examples of companies who put off rewriting and they ended poorly?
Ivett Ördög 00:27:16 As I said, there are certain situations where it is inevitable to regret and I think what can happen is this was actually a project that I was involved in. We kind of had this situation where the product manager would come with problems to us and we would tell the product manager, yeah, we cannot do this because of the system is built like that and that’s getting an airway. And then we explained that for that to be possible we need this amount of time. And we did this a couple of times and after like the tense feature that we couldn’t implement the product manager was obviously very aggravated and it was like come on, we need to build something you can’t save for everything that it’s impossible to build it. And I think that was or signal that it was time for a rewrite or in that case it was more of a continuous and smart effort to refactoring.
Ivett Ördög 00:28:13 But the point is that if your leadership is bought into this concept of, we are not going to rewrite ever, we are not going to invest into rewriting, you might end up with a situation where your team is not really able to deliver anything new for a long time. And if you are willing to challenge the idea of let’s not do a big rewrite in a situation like that, I think it’s okay. It just becomes problematic when you see this effect of a system that is already hard to maintain, and you still stick to this dogma.
Sam Taggart 00:28:53 Let’s revisit the two factors that you found that separate successful rewrites from unsuccessful ones and the first one was to make sure we deliver customer value. How do you measure customer value?
Ivett Ördög 00:29:06 Well the easiest is if you can build a feature that is kind of an add-on that people can buy separately, right? That’s the easiest because then you have an actual monetary value on the new feature. A bit less comfortable one or a less obvious one is adoption rate. So one of the things that I really like measuring when building anything new is how many of our customers are actively using the new feature. Because that implies if it was a useful thing for them or not. And if something is useful, people are more likely to keep buying it or recommend it to other people.
Sam Taggart 00:29:50 This reminds me of something I saw a post of yours on LinkedIn today I think that said something along the lines of observability is better than testing if you have to choose, is that related to this? Because I would imagine that you must have observability in order to know that the customers are actually getting value. Is that making sense?
Ivett Ördög 00:30:10 Yes. This was actually a short that I recently released, and it was recorded at one of my events at a Lean Poker. And this context is very important to understand what I’m talking about there because in Lean Poker people have their own little bots that are playing poker and they’re trying to beat each other but they are playing continuously as they are developing. And one thing that happens very often is that teams don’t realize that their bot is failing and then they keep going on and losing points because they haven’t noticed the problem, right? And what I learned during these events together with people who came to these events is that the best way to stop that kind of situation is to have monitoring and testing is important but often you can omit tests, especially in smaller systems, you can omit the test and rely more heavily on monitoring and ideally not monitoring Twitter if people are tagging your company in complaining messages but more like looking at failure rates, looking at adoption rate of different features, stuff like this.
Ivett Ördög 00:31:23 And this really carries over well into large scale software development because what’s common between Lean Poker and large-scale software development is that you don’t really have a direct connection to all the customers. You might have a connection to a few customers, but you don’t have an overarching view. The only way you can get that overarching view is from the customers and reality is often a lot more complex than you expect. So you can write a bunch of tests, you can have a system that is locked down regarding its behavior to the last if statement, right? But if what you came up with isn’t performance or isn’t serving the customer or the customers finding ways to break that system, the only way you are going to know that is from monitoring. And especially in the first phase of development when you’re exploring what needs to be built. Testing can even be a bit in your way because you might need to change existing tests over and over again because your behavior’s changing. But with monitoring you have a bit more flexibility and also, it actually reflects on reality and every piece of reality, even the things that you don’t expect.
Sam Taggart 00:32:36 I imagine observability is a large topic in and of itself.
Ivett Ördög 00:32:40 Yeah, definitely.
Sam Taggart 00:32:42 I do remember seeing several episodes on software engineering radio about that. I will see if I can find some and put them in the show notes. The last question I have around the two factors that you found, both the making sure you deliver customer value and doing things incrementally, are they both necessary? Do you just need one or do you need both in order to succeed?
Ivett Ördög 00:33:01 The way I see it is if you have both, that’s going to be a project that is usually successful. Having said that, if you have neither, you are almost definitely going to fail with no customer value and an all or nothing project, no sensible CEO or CTO will stand behind that project. Right? And then the question is like if you can let go of either of the two, which one is more likely that you can let go of? And I would say that if you don’t have a clear customer value, but you still have a clear business value, you might still be able to make it work. But then you have to be very diligent about making sure that that business value is clear, obvious and that there is an incremental progress letting go of the incremental progress. I think that’s very unlikely to ever fly because you would have to trust your gut for too long.
Sam Taggart 00:34:00 I think that would go towards risk, taking larger steps would make it riskier, which would then make the business people a little bit more reluctant I think to endorse that project.
Ivett Ördög 00:34:09 And it seems like that everything we talk about today is about risk, isn’t it? The risk of rewriting, the risk bigger factors, the risk of going for a long time without new business value, I guess yes, it’s all about risk.
Sam Taggart 00:34:22 Speaking of business value, how do you convince management that you’re at that point where something needs to be rewritten or refactored and how do you sell that rewriting or refactoring to management?
Ivett Ördög 00:34:33 That’s an interesting question. This discussion is very much based on the talk, that I have and the title there is how do you sell big refactor or rewrite? And here is the interesting point. You might not need to; it might not be the right approach to try and convince business. Well it’s a much better approach is thinking about, okay, what is the value the business needs right now and how can I deliver that value while improving on my systems architecture? And if you come at it from this direction then you don’t really have to convince the business about the refactor. You are convincing the business that the thing that they want you to build can be built the way you are planning to build. And depending on your specific situation, you might be in a situation where you don’t have to share that you are going to do a rewrite as part of this and in some situations, it might make more sense to share this information. It also depends on how technical your leaders are, right? So I would say there is a lot of nuances to when to actually even share this information. But even if you share the point is to make sure that you focus on the business that value that is being delivered and only treat the rewrite as an implementation data.
Sam Taggart 00:36:00 If I understand you correctly, then the advice would be to err on the side of not sharing if you don’t need to.
Ivett Ördög 00:36:07 I wouldn’t say that that way. I’m very much the kind of person who prefers sharing and yeah, I mean I usually have a really hard time not sharing these kinds of information.
Sam Taggart 00:36:19 Well I guess is there a difference between sharing and asking permission, right? Is it like I’m going to do this rewrite or refactor versus I’d like permission to do this rewrite or refactor? Is that a different conversation?
Ivett Ördög 00:36:31 I think it’s a very different conversation. So, so maybe let’s phrase it like this. Never ask for permission. Always focus on the business value and share the decision, your decision to do a particular rewrite or refactor as an implementation detail. And then when it comes to deciding whether this implementation detail is relevant for your leader, consider are they technical enough to need to know this? Is this something that you need their input on? Like are you taking on a bigger risk again, risk comes back. Are you taking on a bigger risk with this rewrite than what you’re comfortable taking on your own without informing them? These are all aspects in usually I would share a very high-level note about this implementation data detail and dive deeper if they ask me to dive deeper.
Sam Taggart 00:37:32 There is a leadership book written by a guy from the Navy called Turn the Ship Around by David Marquette. I don’t know if you’ve read that book it, it’s popular over here in the US. And one of the things that he talks about is having people underneath him come to him and not ask permission to do things but rather say this is what I intend to do, and I think that might be a good model here to go to your boss and say I intend to rewrite this project or refactor this project. Here’s why and here’s the value to the customer to tie this back to your two points because I think they help sell the vision. So here’s the customer value and here’s how we limit risk by doing it incrementally. Does that sound like a good way to approach that?
Ivett Ördög 00:38:10 Yes. I haven’t read the book †Turn the Ship Around. I heard about it a lot and now you make me want to read it. But yes, that’s very good approach of what you said there.
Sam Taggart 00:38:20 Do you have any examples of people selling projects to management and where they’ve succeeded or failed?
Ivett Ördög 00:38:26 Well I can mostly come from my own experience. I think I’ve succeeded every single time once I got to the point where I could very clearly phrase the business value and very clearly show once I know how to mitigate the risk, right? And part of it like this is what we will see, I can be very clear about this is what we will see if I’m right and this is how fast we can move, this is where I can get in a week or two and then we will see the impact already. And if I can do that, I think I’ve never been in a situation where I couldn’t convince my leaders. Even if at the first like sometimes the first answer might be hey okay let’s try this for two sprints, let’s see how far you get and then we, we will decide for real, right? This might be a sensible approach from leadership, but I think that’s a very solid framework for convincing them.
Sam Taggart 00:39:27 It would seem like your answer there also involves the observability that we talked about earlier. Because you’re setting up goals to observe your progress, right? So you would have, if you have like clear metrics or something of like if we do this customer adoption should change by X amount or something like that?
Ivett Ördög 00:39:42 Yeah and one of the things that, going back to that example of this low import process there we had a very clear metric because how did we do that? We simply took one customer that had a problem with that import and their daily import took 25 hours that doesn’t fit the day. So that’s an urgent problem, right? There was already that urgency and I could promise my leaders to deliver a first version that only solves this problem for that specific customer within two weeks and we will be able to measure the difference in speed for the theme import. And then we did that, we went away, actually it took four weeks, not two weeks and I originally planned but after four weeks we had it released and the difference was startling. From 25-hour that import got down to five seconds. Like imagine the difference 25 hours against five seconds. Now that was a really clear business value, right? And there was no question about, continuing this project.
Sam Taggart 00:40:47 So that brings me to another question. Have you ever abandoned a rewrite or refactor in the middle and what happens then and how do you recover from that?
Ivett Ördög 00:40:55 Ooh, that’s nice because again the simple project seems to come up a lot because with that project we then decided to move on and we took other customers and we tried to make sure that every single incremental change that we do unlocks this new import for a bunch of new customers. We went on this quest of implementing features one by one and after about, I think it was like four months, we got to the point where like 98% of our customers had the new import and only 2% had very specific settings that couldn’t be done with the new import. And at that point the business decided yeah, let’s cut this project. We are going to do something else. And was a consequence here, we had to import processes now because this was a rewrite and every customer that that couldn’t be moved to the new import had to work with the old import.
Ivett Ördög 00:41:55 So we had two systems next to each other and that stayed around for another year. What’s the consequence? Next time we had to implement something new to this import, suddenly we had a technical debt of having that few customers with the old system. Turns out in the meantime we lost half of those customers for other reasons and suddenly we only had to implement a few more features to complete the rewrite and then we could delete the odd import. So the moral of the story here is that it might not be a big issue if you have a half-finished rewrite in this sense because you have two working systems. As long as those do work systems don’t collide, you are fine. And when they do then you will have a good business case to finish.
Sam Taggart 00:42:50 I’m just thinking of some rewrites that I’ve seen that have failed and usually it end up when they had two big systems side by side and they were trying to, I think part of it was probably not adding enough value on the new system to drive adoption of it, but the new one hadn’t quite got the adoption that they wanted and then they ended up maintaining two systems and that just got very painful because the new system was always playing catch up with the old system and they’re always trying to add new features and the new features then would need to go into both. And have you seen that type of scenario, and do you have any advice for that or avoiding that?
Ivett Ördög 00:43:21 Definitely and here’s the thing, like the key term that we used there was playing catch up. If you are in a situation where your new system needs to play catch up, that’s a problem because then you are not really incremental. What I mean by incremental is the new system is taking load off the old system and we are continuously moving customers or processes over to the new system and whenever we need to implement a new thing, we should be able to implement it in the new system. And without touching the old system idly, sometimes of course you will have a situation where you have to add in both places. But the point that I want to make is that unless you’re in a situation where, yeah, unless these are small cases where you have to implement both, you are not doing it right, you need to have a rewrite where everything new is only added to the new thing and not to the old one.
Sam Taggart 00:44:19 I feel like a lot of times when people end up in that situation is maybe because the new system isn’t either taking too long or not getting the adoption that they need and then there becomes this like timeline issue where like the new system’s here, but the old system hasn’t seen any updates in so long and they’re afraid of losing people. So like, oh we better update the old system. Is there like a timeline that you should try to keep a rewrite a refactor under in order to like avoid that situation?
Ivett Ördög 00:44:42 Yeah, I mean again, if we have a risk of losing customers because they are on the old system, I would again ask why are they solely on the old system? Could it be that the two systems are integrated in well enough that it becomes transparent for the user? Which system are they using? Right? And if that’s the case, then you don’t have that problem with our import example, the user didn’t know that there were two imports because there was a part of the system that would decide can we handle this with the new one and if yes, we would handle it with the new one. If no, then we would handle it in the old one. And if there was a new feature that wasn’t implemented in the old and we had, also an old feature that wasn’t implemented in the new one, then we might actually say on the UI that hey, these two features cannot be used together, sorry.
Ivett Ördög 00:45:35 And then it becomes a discussion of do we implement this in the new system? Is this customer important enough? So in general ideally that that should be case. Now there are of course situations like for example the Prezi rewrite where they had to move from action script to JavaScript. There was no option like to make this transparent for the user. This was actually two different systems and there you actually need to accept the fact that you are going to lose customers because you can’t, like they couldn’t even reproduce the same system. They ended up creating a new presentation software that works slightly differently and has slightly different features. So there they had to accept that there will be customers lost.
Sam Taggart 00:46:27 In the example I was thinking of, it was a desktop app and they were changing languages actually, so that required two separate executables and so that, I think that was part of their problem. I wonder does having, a web app make that easier doing something like the strangler fig pattern where you like run the two side by side and then you slowly switch people over? Is that a useful pattern?
Ivett Ördög 00:46:49 Yeah, that’s true. Like my experience shows in this regard. I have always worked in web systems and never on desktop apps, so I’m not sure I would have good advice for desktop apps. Having said that, I think the Visual studio to VS Code shift of Microsoft is a good example of a desktop app being rewritten. And I think what was interesting there is that they consciously aimed at a different market, right? So VS Code was designed for people who would never consider Vision Studio and because it was for a different market, it was basically accepted that they will have two systems for a long time, and it took years. I’m not even sure if Visa Studio is still a thing. Probably it is. I’m not that deep into the Microsoft ecosystem. But the point is that when you have that kind of rewrite where you are basically creating a new software, they the business value should be opening new markets and accepting that the old markets are going to be served by our old product for a long time to come.
Sam Taggart 00:48:03 Yeah, that is my understanding that Visual Studio itself is going to keep going and VS code is its own separate thing. And like you said, I think they were targeting a separate market. In the case that I was talking about earlier they were trying to replace the old one with the new one and they were not targeting a new market.
Ivett Ördög 00:48:19 Yeah, I would probably advise against that unless you can make sure that the two systems are integrated in a sense. So the key thing is that you’re always delivering a full featured app. You are either always delivering a full featured app or you are delivering a different app for different market. And if you can do that, then I think it’s fairly safe. If you can’t, your mileage wave may arrive. Like I don’t want to make very categorical statements here.
Sam Taggart 00:48:48 In this particular case it did not work out very well. So it would’ve done well to heed that advice.
Ivett Ördög 00:48:52 Okay.
Sam Taggart 00:48:53 Thank you very much for talking to us.
Ivett Ördög 00:48:55 Thank you very much.
Sam Taggart 00:48:57 For SE Radio, this is Sam Taggart. Thank you for listening.
[End of Audio]
