Dealing With Legacy Code with Debbie Madden and Jason Ables

Transcript

Ledge: Hi, welcome to Gun.io’s thought leadership session on Legacy Code. I have a couple of guests here with me: Debbie Madden, CEO and co-founder of Stride Consulting in New York and Jason Ables, COO of Ethode in Cleveland.

Debbie, why don’t you give us a quick introduction of yourself

Debbie: Thanks! Hi, everyone! I’m Debbie Madden, co-founder and CEO of Stride Consulting. Stride is about Agile software development consultancy. What that means is we send seasoned teams of software developers to embed with existing tech teams to help them be the highest functioning version of themselves whether we code alongside them or help mentor them in Agile engineering practices or help bridge the gap between product engineering and stakeholders. We’ve been doing this for about fifteen years and we’re happy to be here.

Ledge: Excellent! Jason, how about you?

Jason: Hi! I’m Jason Ables. I’m a team coach and the COO over at Ethode. We are primarily a web development shop focusing on open source technology. I’ve been involved in the web since the mid-nineties back when AOL and dial-up was a big thing and bbds and all that good stuff.I had my first Geocities page with the “Under Construction” animated gif, so I’ve been doing this for a while. I’ve seen my fair share of rewrites in legacy code. I’m looking forward to the talk.

DAVID: Great! Today, we’re going to work together trying to drop some wisdom on how to deal with those legacy code issues.
Both of you have written about how to deal with the business and technical challenges of legacy code, and we’ll get into that a little bit later.

But, first, I’d like to ask each of you to talk a little bit more about the root issues that come up; and one of the questions that everyone asks when they first fire up the coding environment is “How did we get here? Where did this come from?”

Ironically, that’s the first question that business users and budgeting leaders are going to ask when they are addressing technical leadership except they aren’t looking at the code; they’re going to look at the business results of that code.

So let me pass that to each of you: How and where do messy legacy code situations arise in the first place?

Debbie, why don’t you kick that off?

Debbie: One of the interesting things that I’ve seen in the last two years is the definition of what makes code “legacy.”

Back in the day, in order for code to be considered legacy, it had to be decades old; and I started going to meetings, and code that’s three or four years old is being considered legacy. So it’s interesting to me that the definition of “legacy code,” at least, in terms of how long ago it was written has changed by a factor of five or six years recently.

A few years ago, I would have said, “How did we get here?” Well, code was written before things like test-driven development were created, and the modern practices have evolved; and it’s not necessarily that the code is broken but, sometimes, it’s just not using the modern best practices that we are accustomed to today in many environments.

But that’s not always the case. Sometimes, it’s the case that what I would consider relatively new code is considered legacy, too. And “How did we get here?” ─ it could take an hour just to answer this question. But some of the common things are: just the factor of time ─ code that was written a long time ago like, let’s say, a version of Java that has been modernized five or six times (Java 2, 4, 5, 8 and things like that).

Or a team never thinks that they’re going to succeed. And so, they just cut corners and throw spaghetti code against the wall just to see if anyone wants what they’re selling, which is often the right thing to do at the time; and they kind of get crushed by their success and never go back and fix the brittle code.

So those are some of the things that ─ Jason, I see you nodding. Feel free to add more but some of the things that I’ve seen are the ones I just mentioned.

Jason: Yes. I think a lot of legacy code comes out from good intentions. I don’t think any developer sits down and goes, “You know what, I’m going to write a crappy code today.”

A lot of it comes from external forces. And the reality of the situation is you never have all the time and all the money in the world to sit there and write the best code in the world.

So I think a lot of that comes from external pressure from the business ─ and maybe you’re hiring junior developers and maybe you’re sending it offshore or something like that to get the job done as fast as possible.

I think a lot of this comes from when there’s a lot of focus on speed over quality and going with the lowest bidder in a situation. So someone naïve coming through a situation says, “We need to get all these features done. We have x amount of dollars to spend. This developer is charging me way less. Let’s go with them. I don’t see why not.”

So I think a lot of it comes from poor executive decisions and not really doing your due diligence on checking out to see if a development shop is good or not.

But even when developers are coming with the best intentions and even if they’re good developers, they may be under pressure to say “Okay, what are ways we can make this even faster? Can you, guys, just not write tests? Let’s just not write tests. It’s only going to be a prototype. We just need to get it done for this demo next month and as long as we have it done for the demo, we’ll be all good.”

And someone is like, “Well, I don’t know if we should that.”

And then, the demo comes by and they go, “Okay, great! Demo went great! And here’s the thing: They’re going to give us more money if we can get this one or two extra features in there. Promise, promise, after that, we’ll get back to the refactor.”

And then, several decisions later, suddenly, you’re looking at this pile of mess after a year. It doesn’t take long to get to spaghetti.

You could take six months. It can take a year. But, after a while, now you’re at the point where maybe you’re starting to run out of budget and maybe the developers are getting frustrated. Maybe there’s a developer who is a senior developer who has been arguing against this the whole time and they say, “You know what, guys, I’m fed up with this code base. I am done.”

The senior leaves. Now, you’re just stuck with junior developers. And, now, it becomes even worse. You have no leadership and it just continues to be this ball of mud that expands over and over throughout time.

So a lot of that comes from no coding standards and no automated tests; and then, once one developer leaves, then, you can start to get into a high turnover culture.

I’ve seen this before as well where one person leaves and I was like, “Well, I like working with that developer. The reason I was sticking through this crappy code was because we had the team to go with it.”

And so, now, once one developer leaves, the others leave; and, now, you’re in this high-turnover situation and you have a whole new team coming into this new code base to work on this code and they go, “I don’t know how to read this stuff. I can’t find the login class because it’s not set up in a way that I’m used to and with the framework I’m used to. So I’m going to write a new login class to do basic logging stuff.”

And, now, you have two or three different login classes that do the same thing.

The other thing you can see, too, is when you’re working in a firefighting kind of environment. So everything is a high priority. You’ve got maybe some kind of aggressive CEO and everyone is listening to the CEO. You’re in a culture where people are afraid to say “no” to people so it’s like “Whatever the new feature is, whatever the sales team says we need, we absolutely have to get this done today. So whatever you’re working on, stop that and start working on this.”

A lot of in-progress work that never gets finished, I think, leads to legacy code as well.

Debbie: One of the things I see often ─ one of my developers last week was giving a demo to the stakeholder and I said, “How are you feeling about the demo?” and he said, “I’m really nervous because almost all of the progress is behind the scenes, under the hood.”

So he was taking that discipline and that time to do the things that are necessary to create code that is maintainable and robust over time; and he was afraid he was going to get reprimanded by the stakeholders for it because they weren’t going to be able to see a shiny new feature.

It was critical for the success and the foundation moving forward but, in that moment, that “show me what I paid for” phase, that’s where their corners get cut, as Jason said, and, sometimes, it’s easier to just put that sideways and rewrite the whole thing and not deprecate the old stuff. Then, you get into the situation of unnecessary complexity and confusion and that’s definitely something that occurs, unfortunately, too often.

Ledge: Right! And yet, we all know that there’s never once been a budgeting meeting where someone said, “Hey, I have an idea. Let’s spend some money on a refactor.” And, as technical leaders, maybe we bear some of the responsibility of just many times having failed being able to demonstrate our value to business leaders.

If you can’t explain to a business leader ─ and I’ve been on those both sides of that fence; you have, too ─ why should I spend money on that? What do you mean? Why didn’t you do it right the first time?

And, in their mind, that sounds like a reasonable question. I’m deviating a little bit here.

How do you answer that question? Again, it’s like if you did it right the first time, we wouldn’t be here.

JASON: Right! I think that’s a great point because you can be in a situation where maybe you have and maybe you just haven’t documented it. So do you have any documentation showing that those conversations have happened because it’s easy to forget

Ledge: Did we make this decision?

Jason: Right. It’s got to do a risk analysis. What are the risks we’re making here? What are the assumptions we’re making? What are the tradeoffs we’re making when we’re deciding to rush something to hit some kind of demo next week?

When we’re saying we’re sacrificing quality, that’s what we mean. We need to schedule in time to go back and fix that. Most people are familiar with the term “technical debt.” It’s okay to take on technical debt if you have the ability to pay it off.

So one of the best analogies you can try to give to someone who doesn’t understand tech as well is to say, “It’s just like if you’re starting off your business and you have a $20,000-dollar limit on your credit card. You can go out and buy all the stuff but, at some point, you’re going to max out that credit card. At some point, that interest is going to grow to a point where you’re going to be paying more on the interest and you’re going to be stuck in debt forever.”

So you need to make smart decisions when you take on debt.

And so, if you’re going to take on a short-term debt to hit some kind of objective like being in sales demo or something like that, then, you have to pay it off.

And I think, as a technical leader, you need to say, “Hey, here’s what our debt-to-income ratio looks like. The higher this debt goes ─ just like the way it works with cash flow. If you don’t have cash flow in the business, you can’t operate.

If we don’t have technical flow ─ so as we accumulate that debt, our ability to deliver features slows down. At some point, it’s going to come to a screeching halt and that’s when we hit a technical bankruptcy.

And I think that always has to be part of the conversation. It’s like “Are we going to prioritize this new feature or are we going to go back and work on something?”

It doesn’t make sense to be flying down the highway and trying to change the wheels in the car at the same time, right?

And another thing is if you’re not building the proper foundation, eventually, that’s not going to work. If you’re trying to build a skyscraper on quicksand, you’re just doomed for failure.

So, at some point, you need to get that foundation stable and you have to invest in that as early as possible because the later you wait to do that, the more expensive it is to fix it. The longer it goes, the more money it’s going to cost and the less of an ROI you’re going to get.

Debbie: For me, from a stakeholder perspective, I think one of the things that I have come up against is that you have to explicitly tell people and have the conversation ─ you can fix one variable; you can fix how much this thing is going to cost; you could fix the scope; or you can fix the due date.

But you can’t fix more than one thing and I think that’s something that is abused all the time and that’s one of the things that gets people into trouble because they say, “Oh, well, I was promised this thing on this date for this amount.”

Nothing in life works that way. And I think it’s having that conversation and often and, as Jason has said, in writing. I’m not talking about the contract because I’m very adamant about the fact that contracts are not agile and that’s a whole another podcast.

But with the business folks ─ listen, you have to understand. We can do what you ask but you have to understand what you’re prioritizing and the tradeoffs. If you are tied to the holiday season and you absolutely must get something out by November 20, then, we might not get all of your features; and if you have a brand to protect and it has to work, then, we have to have time to protect the code, clean up the tech debt, build that solid foundation which means you might not get that shiny feature but the checkout process will work.

I think it’s important to have those conversations early and often and really embracing Agile at the business side of things and having your stakeholders be part of the planning process. You can ask for what you want. You can be in control of what is number one and number two priorities as long as we are able to say, “Listen. It’s not going to happen” or “If it happens, it’s probably going to crash. Sure, we can throw something together but your thing might not work.”

So people have to get used to the reality that they’re risking some things. If you ask for A, then, you’re risking B. If you’re asking for scope, you’re risking quality. If you’re asking for scope, you’re risking budget.

Jason: Yes. I think there are tradeoffs all the time. So when you’re looking at someone who’s completely focused on speed and boom, boom, boom, they’re like, “You know, I read about stretch goals. You need to get people stretch goals” and that’s all they’re focused on, you could say, “Well, I need to get to the airport and my Uber driver is going to be here in five minutes. But there’s a bicycle in the garage so I can get the bicycle right now but it’s still going to take me an hour to get to the airport if I use my bicycle so just because I have access to it right now doesn’t mean that’s a good decision. I’d much rather wait for five minutes until the Uber driver shows up and it only takes me twenty minutes to get to the airport.

Ledge: You all are reminding me of the ─ I’m sure you all know Steve McConnell: “The problem with quick and dirty is that the dirty remains long after the quick has been forgotten.”

Jason: That’s is so true.

Ledge: And that happens to us a lot in software. I read a comment on Stack Overflow when I was researching our topic. Jerry Coffin is a highly ranked Stack Overflow writer and commenter and he said, “Code is often retained as legacy, even when it really shouldn’t be. Higher level managers generally assume re-implementing a system will cost as much or more than the initial implementation did, which is rarely true.”

I want to dig into that a little bit because we all know “What’s it going to cost?” is the first item on a business leader’s mind and, therefore, it has to be the first thing on the technical leader’s mind because that’s who everybody answers to, ultimately, in finance and sort of the executive suite.

How do you think we should address that? When is the right time to think about reimplementation?

Maybe it’s not as awful as we think it’s going to be. We have all seen that technical folks like ourselves may be, sometimes, overestimating how awful that is. Sometimes, we don’t. And how do you know the difference?

Jason, I’ll kick it to you to start that one.

Jason: As tech people, especially early in your career ─ you’re not thinking about the business side of things. You’re thinking about how much you want to do this rewrite, how much you want to get out of this ugly code. And so, you’re going to paint a picture that’s prettier than what’s actually going to happen.

The thing you have to remember is all that’s going to do is make you lose credibility. So you need to be realistic. It’s always going to take you longer and you’re always going to be overly optimistic.

So developers tend to think of rewrites in terms of weeks and months. It’s probably more like years.

And if you’re looking for a person on the business side and you want to break that down into hours and days, that’s not going to work out right.

I think the first thing is to just be upfront about the uncertainty and try to communicate how unpredictable the process will be and that we don’t know what the final cost will be. And we have to accept that.

A lot of times, you’ll get feedback to say, “Well, you’re a professional. You should know how long it’s going to take. “
One of the analogies I like to give is that a lot of people watch football and I’ll say, “Okay, how long have you been watching football?”

“I have watched football since I was a kid.”

So I go, “Who is going to go to the Super Bowl this year and what’s the score of the game going to be?”

Well, you don’t know yet because there are so many factors that are going to happen, and that’s just in the game of football.
Software is infinitely more complex than that. So I think what you need to do at that point is to start selling them on the process instead of the estimate.

And I think what you can do a) try to find an early win and b) find out what the most complex thing is. So try to find something very simple. Maybe it’s a contact form or something like that or something very simple. If it’s like a web app or something like that, maybe not a whole lot of people are using that. And then, say, “We’re going to use this little slice here just to kind of test the waters. What we’re going to pull out of this is we’re going to get an idea of what the best possible refactoring situation is going to look like.”

So you refactor that a little bit, and then now you’ve got a baseline of what the best-case scenario is going to be. And then, you say, “Okay, does this look like something you want to proceed with?” and, from there, you can say, “Okay, now, let’s try to tackle the riskiest part of the application or maybe one of the more complex parts of the application, something where you can get an anchor on the other side of how long something really complex is going to take.

Yes, we’re going to spend a little money here and we’re all going to acknowledge that this is uncertain.

But you can pull the plug at any point. You can set like a baseline. You can say, ‘Maybe we’ll work on those complex sections for no more than two months, and that’s when we pull the plug.’”

So you’ve set a time barrier. And then, you can come in and once you’ve refactored that section, you now have a section that didn’t take too long and a section that took a while; and you can say, “We can say with some fair certainty that it’s going to fall somewhere between either that best-case scenario or that worst-case scenario.”

And then, you can go through and say, “How much of the app we have to do?” and then, from there, you can say, “It can be an incremental funding thing so we don’t need to come up with this base cost right now; we can say, ‘If this is all we have in the budget to do this amount of refactoring, then we can start with just these main features.”

And then, try to go for those little wins, and then just try to get budget approvals after each win. So look at it as an incremental funding thing as opposed to one big huge project.

Debbie: Yes. I definitely agree with everything you’ve just said. My reaction to reading that Stack Overflow comment was that Jerry has the wrong formula. He is asking “What is the cost of the rewrite compared to the cost of the initial implementation?” but the cost of the initial implementation is sunk cost. That money has already been spent and it doesn’t matter how much money it cost versus how much money it’s going to cost.

The only thing that matters is “In the next twelve months, this is my budget. What are the most important things to be spending that budget on?”

And if you’re business has three projects, ten projects, one project, what are the most important business value-added things that you could be doing to generate the most profit for your business?

And if that means rewriting all or some of your legacy application, then, that’s where that money should go. If it means building a new application, spending it on marketing, spending that on places outside or the code, then, that’s where it should go.

So I really believe that that whole way of going about thinking about the rewrite is you’re comparing it to the wrong thing; and it’s much more important and much more valuable to the business to think about “For every dollar that you have to spend, where is the best way for you to spend it?”

The second part of that is “It is a myth that you have to rewrite your entire code base or not.” That is simply not true.

Jason, I know that you started to talk about that and it is very possible that there is a 20-year-old, a 10-year-old, a 5-year-old part of the code base that is just fine. It’s probably written in an old tech stack, it’s probably not fully tested. But if it works and it’s not on the critical path and it’s not your competitive advantage and it’s not on your top ten party list, there’s no reason to get rid of it just for the sake of making it in React, because React didn’t exist back then.

And you don’t have to. It’s very possible to find the seams go into that legacy code base and find ─ as Jason was talking about ─ the easy places to start, the business places to start, and have kind of the best of both worlds.

It’s called like a “strangler approach.” Don’t do ─ as you say ─ one-to-one giant approach. Really look at it as smaller chunks, if you will, inside the code base and really ask yourself which pieces are required.

If there’s something where you’re getting customer calls all the time, if it’s losing you money, if people are angry about it ─
Another option can be just to deprecate, to shut it off. You don’t have to actually rewrite it. You could just say, “You know what, we’re getting negative feedback on it. It’s clunky. It’s broken. And, by the way, it doesn’t actually generate value for the business so let’s just simply stop using this entire product or code base or part of the code.”

That’s another option as well.

Ledge: On top of all that and the excellent business reasoning of those descriptions, there are times when ─ Jason calls it the “Big Rewrite.” Debbie shows maybe 25% of the time in the work that you do or in the modelling that you’ve put together that it’s time to tear down the building, blow it up like a legacy old foundation that can’t hold up the skyscraper anymore and then start over.

And that’s terrifying. It’s terrifying for business leaders and technical leaders because they know they’re tromping out into the great unknown. But when do you scrap it and start over? And how do we handle that?

Debbie, I’ll kick it to you first.

Debbie: The consultant in me has to say, “It depends.” There is no black and white answer. But I view this as almost like a visual path through the system. My question number one: “Is this code in the critical success path of your business? If yes, is it broken?”

You really need to answer the question, “How much is having that code costing you?” and you really need to sit down and run the numbers.

If it’s going to cost you $100,000 dollars or $200,000 dollars to rewrite the whole thing or the majority of it and you believe that within twelve months after completion, you will double your profit margins or gain a million dollars or land that key customer or break into the new vertical, then, it’s worth it.
This is, in essence, part of the conversation teams and business owners need to be having around annual planning. My entire leadership team uses Agile. We have weekly Scrums. We have prioritized backlogs. We have annual initiatives. And every single week and every single month and quarter or year, we ask ourselves, “What’s the most important thing?”

And here’s the key. You have to define what “good” looks like and measure progress towards that.

If “good” looks like you are retaining x percent of your customers and you fall below that, well, do the “5 Whys.”

Why are we losing our customers?

Because they can’t log in.

Why can’t they log in?

Our code stinks.

So if you land at “This piece of code is critical to our business and the reasoning for our bottleneck is the quality of the code,” then you need to rewrite your code and you need to seriously consider investing in it for the long run.

Before you rewrite it, you need to understand what “good” looks like when you’re done or else you’ll never know. Once you start to rewrite it, you could be doing this for infinity. You can always have another test. You can always refactor. You can always add a new feature.

Before you get into this mammoth undertaking, it makes good business sense to think about “At the end of the day, what do I want to achieve with this?” so that you know when you get there.

Again, if I want to become a marathon runner ─ which I do not ─ I would want to know, “Okay, how long do I run the marathon? How many marathons do I want to run? How many times a week would I need to run?” I wouldn’t just go out and start running. That’s not practical.

And I think if we really take a profit margin financial approach to a business and really kind of go through that “Yes, no, yes, no ─ is it critical? Is this the reason?” that’s where I see could lead to success. If you come to the end and you say, “Yes, we need to rewrite; we feel confident, in our reasoning, we’ll prepare for it to take around these many person hours,” great, then, let’s do it.

Jason: Yes. I couldn’t have said it better myself. I think, from a technical perspective ─ first of all, it’s a garbage in, garbage out kind of thing. Mess begets more mess. And so, I think that applies on both the technical side and the business side.
I think you can be empathetic towards the technical team by explaining, “We can’t be as rushed and sloppy on the business side in the same way that we can’t be rushed and sloppy on the technical side.”

As you were saying, you have to say, “Why is it that we want to do this big rewrite? What are the pros and cons of it? We have to expect that it’s going to take a long time. Whatever the initial estimate is, it’s probably going to take longer than that. So we just have to come to terms with that and ‘Are we willing to accept that risk?’”

A lot of it is just about your ability to accept risks. If you’re in a situation where you have time and money to throw at the problem, then, that’s a good time to do a rewrite.

Debbie, I think you mentioned in your article that the future is more important than the short term, right? So if you have enough resources available to say, we want to invest in the future and we’re okay with some short-term risks that this is going to take on, the code is stable enough that we can keep the legacy code intact ─ maybe why we write the new product.

This is kind of the same approach that the 37signals team took with the rewrite at Basecamp. So they kept Basecamp Classic while they took a whole year and put a whole other team on Basecamp next.

That’s the other thing that I would advise. It’s not to have the same team working on both the legacy code and the new code base.

And you also ought to look at the risk of that. From a business standpoint, if everyone is not on board, then no one will want to be in the team that works on the legacy code base while the other team gets to be the ones working on the fun stuff, right?
So you’re going to need some real soldiers on the team if you’re really going to go down that route and you need to have that conversation up front, “Hey, are there people who are going to maintain the legacy code base, at least, to keep it stable and to make sure that we’re going to stabilize any critical issues that come up?”

And from a business standpoint, “Can we agree that we’re going to accept the risk of not adding new features to this old system?” because, in doing so, it’s going to complicate the eventual transition to the new system. “Can we all agree to that?”

Those conversations need to happen as soon as possible, not six months down the project when they say, “Hey, we need to add this new feature.” “We’ve agreed not to do that.”

So if you can afford to freeze the product, if you can afford to invest in a long term, if you’ve got the executives on the team who understand the long-term return on that investment and you’re looking at things like “How long does it take for a new developer to get up to speed?” if every time you have a new developer coming on the team and it’s taking them months to get to the point where they can add a new feature, then, that’s a very good metric you can deliver to the financial team.

“Look, if we can get this code base cut back we can get someone up and running in days instead of weeks or months. That’s a major return on investment. And if we have this new system in place, what’s now taking us months to get features in place, we can do in a matter of days or weeks, in a matter of a sprint or so.”

And I think those are good numbers and metrics to go by. And, as you were saying, Debbie, if you have a churn, if your customers are jumping ship, that’s a number you can go by.

So when you get the first bit of the rewrite out there, can you get a prototype out there that’s under automated test, that’s cleanly coded and then can you get some new customers on that platform and can you show on that new platform early on how much faster you’re able to spin developers up, how much faster you can deliver features to the market, and how much customers are loving the new product?

If you can get that little win, then, you can go for major rewrites of the code.

You can also look at it as “We’re just going to rewrite the major MVP kind of portions of the code.

I think FreshBooks did that, too. I think FreshBooks has FreshBooks Classic in the new FreshBooks and they’re allowing both people to stay on both systems. That’s an option you can do as well. It’s the same thing with Basecamp did as well.
I think if you’re in that situation, then go for it.

If you’re not willing to accept the risk that this could go way over schedule, that it’s going to go way over budget, then I’d say you shouldn’t take on the rewrite.

Ledge: I like that ─ FreshBooks and Basecamp. We have a tendency ─ all of us ─ to think of legacy code maybe as a bad thing and we even started off on that tact at the beginning of this discussion looking at all the negative pieces of that.

I read another quote by Jonathan Boccara and he said, “In most cases, we’re here thanks to legacy code” and not just we being the technical people.

The early stages of a project or a product where great things happen and we start to grow and we capture clients; we build up financial interest, maybe technical equity versus technical debt; we establish a brand and we’ve got customers ─ all of that happened with the code that we had and it might still be around today and it might still work. And, some customers, maybe they still love it. They still love the idea.

And that is legacy code. It’s our legacy as a business. There is sort of an emotional hook about that.

On the technical side, none of us would have jobs if, in fact, there wasn’t legacy code. So we have to be a little grateful for that as well in a non-cynical way.

I wonder, do you encounter that with clients ─ that there’s an emotional attachment and honor to those who have fallen before us and we shall not declare their code to be garbage

Jason: I think there’s some aspect of that. There are different perspectives on who’s looking at it as legacy code. Are the customers having a problem?

If the customers aren’t having a problem, to them, there’s no such thing as legacy code. The application is working fine. Features are getting delivered on time. There’s no business sense to change the code ─ at least, from that perspective.

Now, internally, from an operational standpoint, if you’ve got a high turnover rate because of really poor quality code ─ no developer wants to work in a system that is un-maintainable.

So it really depends on how poor the code is. If you’re in a situation where that legacy code is, at least, refactorable so that you can go and make changes, then, I think there is some pride in being able to ─

I love going into a crappy code base and being able to get little wins. I’ve done this several times for clients like coming into a system where sirens are going off and the system is shutting down every day, and then you can, at least, stabilize the system. There’s some fun in that. And it doesn’t require a major rewrite to do.

So, yes, there’s some pride in that.

I would also go so far as to say that if it wasn’t for my experience with legacy code, I wouldn’t be here today. I wouldn’t be able to advise people on what not to do.

I think, a lot of times, you learn a lot of valuable lessons by working on a crappy code base. You’re like, “Wow, that’s why dependency injection is important. That’s why the MVC pattern is important.”

This is why it’s really important to make sure you check in early enough on your code. This is why it’s important to not just write for yourself but to understand that other developers are going to come in and read the code after you do.

So I think a lot of junior developers especially ─ when you’re just starting off in your career, especially for people taking online courses, you’re always starting with this nice greenfield project where you’re getting to start the whole thing from scratch when the reality is you’re coming into a corporation or something like that, and this code base has been around forever.

Here in Cleveland we have Progressive Insurance. They make a joke and they say they’re an IT company that sells insurance because there are so many people working on this code base so they’ve been migrating into C Sharp forever, it seems like. It’s a perpetual rewriting of that code base.

Yes, that legacy code base is around. It’s delighting customers. It’s teaching you what not to do. So, in that regard, you can be thankful for it.

But, still, you should be able to refactor it or, in the rare circumstances, sometimes, do the major rewrite as well.

Debbie: I appreciate that and I definitely agree to some of what you just said. It’s funny when you started talking about the emotional attachment. It made me chuckle to think that someone was viewing code as an heirloom that must be protected and that was irreplaceable.

It’s not someone’s wedding ring passed on from generations. It is, in fact, a piece of code that is ─ as Jason said ─ valuable and we can be thankful for and it’s viewed by many as an enjoyable problem to solve to make it even better.

I have not come across many people at all who say, “I wrote this code. It’s mine. I’m emotionally tied to it. Please don’t rewrite it.”

Most people say, “It’s mine. I’m emotionally tied to it and I know it stinks.”

The founder or CTO who got the company off the ground is very proud of her accomplishments and they will say, “I wrote it and I’m not the best person to take it forward and I fully admit that it’s not as good as it needs to be or as it could be.”
So it is very rare to see someone holding on to something that’s not good for the business.

One other thing I want to bring up is that I come from the business side, as you can guess. I’ve been running Agile software engineering teams for almost 20 years since Agile was practically invented.

But I’m not on the implementation side. I’m not a software developer. In fact, I am on the team side of things. So my perspective of Jason is really interesting. Even for me to listen as we’re talking about this ─

One parallel here is that there’s something called the “Greiner Curve” and that was literally invented in the seventies and popularized through Harvard Business Review; and it talks about the alternating periods of chaos and calm that all enterprises, companies, and startups go through. As you succeed you go up and say, “Oh my God, this is great!” and then you hit a wall and ─ boom ─ you go down, and then you go back up.

And it’s through those kind of like valleys of death, if you will ─ if you can make the leap over to the other side ─ you might have heard of “crossing the chasm.” There are a lot of ways to depict this visually.

If you can make it through that period of chaos, you are rewarded by another period of calm, and then another period of growth.

And so, in these times, organizations, this is where you replace your founders with hired guns, if you will. This is where you place your leadership team hire different types of employees.

And code also goes through these patterns. So we are here because of the legacy code. It was the thing that got us started, in many cases and, like with the business, it also parallels. There are periods where instead of being an asset, our legacy code starts to be a crutch and starts to hurt us and starts to slow us down.

And we can separate. We can say, “It is what got us here today and it is no longer the thing that’s going to get us where we need to go tomorrow.

Listen. It’s not me. It’s not personal. I’m not doing anything wrong. In fact, it is because we are succeeding just like with our team and our people inside the code, we go through these periods of chaos and calm; and when the legacy code is no longer serving our best interest, it needs to, in part or in whole, go away.”

So I think that’s how I would look at it.

Ledge: I would agree with that in my own experience. And sort of being in the business of high-end software engineering, we encounter a lot of folks who, I would characterize, are less of an engineer and more of an artist; and the code is poetry and that “I feel like I know the right way to do it.”

And to have to break those things down in teams in an Agile setting is interesting for all of us. I’m sure you’ve all encountered that.

We talk about software engineering and yet, there’s an artistry and sort of stronger connection to the code than one would think if I put up some steel girders for a bridge maybe.

Jason, you’re nodding. But do you see that with senior sort of engineers types that “Hey, look, we’ve all got be aligned around this”?

And I think a lot of the legacy code ideas ─ the negative side ─ come from maybe the artistry of going “That’s not how I would do it” or “I actually want to tear it down and rebuild it because that’s more fun for me.”

You have to balance that from a business perspective.

Jason: Right. I think that’s kind of natural. I think it goes with anybody who has their own way of doing things. You could walk into a room and you’re like, “I wouldn’t have have the couch right there. I wouldn’t have to chair right there. That’s stupid.”

If you’re an artist or a designer, you walk into a company and may go, “This logo is dumb. This logo is stupid. I would totally would have done something different. This is using some kind of thing that was popular in the mid-2000s. It’s so outdated. Let’s redo the logo.”

So I think it’s kind of a natural tendency for creative types to want to do that, to want to put their own stamp of their creativity onto something.

I think the difference with a software application is huge. You’re not just moving a couch around. You’re not just re-sketching a logo. You’re talking about taking a lot of work to put your stamp of approval, to put your own little design brand on it.

And so, I think as you become more professional in your career, you come to accept that every developer ─ I look at a code base and go, “You know, I have no idea what these people were under. They may have been under a tight deadline. I don’t know what circumstance they were in.”

So you try to walk in saying, “This person probably had the best intentions and they were probably doing the best they could with the knowledge they had at the time they wrote the code” because writing web apps in the year 2002 is a lot different than it is in 2018. There are a lot of tools and libraries we have at our disposal now that weren’t around back then.

And so, if you’re working on a code base that was written in 2002, you can’t be like, “Wow, what they did is so dumb. It’s so stupid.” It’s more like just going, “Wow, that’s an interesting way to solve that problem. What would I have done if I didn’t have ─ like what you were saying ─ if there’s in React or something like that. “What would I have done without these tools or without MPM or something like that? How would I have solved these problems?”

Taking that into consideration and understanding that it’s someone else’s work and respecting that, I think, is key; and I think there is a little bit of pride and I think you can still get that pride by going in and saying, “I don’t need to do a massive rewrite to put my brand on it.” I can go in and say, “Look, this is how you refactor code. This is how you do it while you’re doing other stuff.”

You go in. If you’re going to make a feature change, you have that discussion with your product owner. You say, “Hey, while we’re making this change, I think it would be advantageous for us to refactor this a little bit so that it’s going to be better the next time” or I would even argue, sometimes, If you don’t have that kind of trust, go kind of skunkworks on it.

As a developer, if you know that it’s going to be better, then just go and do it. And, sometimes, that might even mean putting in a little extra time. It depends on your level of comfort.

I don’t necessarily recommend this for everybody but I remember being in a company where we were in a situation where we didn’t have an ORM basically. And so, there were all these handcrafted queries everywhere.

And I knew in my heart of hearts that if we refactored that, it would speed up things. And so, every night, I would work on that a little bit. I would stay over at the office.

I wasn’t impacting the company’s budget. This was my own decision that I was making on my own time.

I think, at the end of the day, my IT director at the time ─ I was like, “This was what I’ve created.” I said, “I worked on this in my own time. It’s not like I was eating up budget. I’m on salary. It’s just like I was charging anybody per hour. But this is how much I believe in it.”

And then, the other developers loved it. Our productivity increased. And that bought me some leverage to authorize some more refactoring going forward.

If you’re on the technical side, business people always value skin in the game. And so, by doing that, you’re showing that you have skin in the game. You’re showing that you’ve really invested your time to prove how valuable it is to do it. And I think if you show some of that, they can give you some leverage on the business side to say, “This person is taking this really seriously. Maybe we should listen to them. They’re not just doing it just to ─ whatever ─ because they want to goof off on some new technology.”

Debbie: I think one of the things that I would add ─ I like what you said, Jason, but the one thing made me nervous. When you talked about productivity, I think that, absolutely, if you see a way to improve things, if you have skin in the game, if you’re passionate about it, those are all amazing things.

For me, we like to throw in an anti-goal, if you will, to kind of make sure that those good intentions don’t actually deter the greater good and that is, we focus on and we distinguish between team productivity and individual productivity.

I think that, for me, is like a key piece of the recipe here.

So if there is an opportunity for someone to make something better, it really does have to be better for the team and not just to show off, if you will.

Jason, I think you were talking about that like you saw this opportunity and “It increased our productivity and the other developers loved it.” For me, that’s the key because, without that, it’s very risky to have folks going off in all directions. You come back in the morning and “I did this. I did this. I did this” and then, we come in the morning and we actually set ourselves back and then we’re kind of working off in three different directions.

As long as you can maintain that high team productivity, whatever that looks like for your team, then I’m all for it.
Does that make sense?

Jason: Yes. It does. And I think the part of the story I’m leaving out is the many months beforehand where developers are pow-wowing over lunch or just like cubicle talk back in the days when cubicles were a thing.

So just talking ─ when you hear the same problems come up and you keep telling it to the project managers, “Hey, we need to fix this” and then, no one is listening to the tech team and you all know how much it’s going to benefit.

I was a soldier who took one for the team.

Debbie: Right.

Jason: I believe in it so much that I’m going to stick around at night and work on this.

And so, yes, it’s definitely something that you don’t want to just like throw in some kind of weird library because you think it’s cool and everyone is like, “Dude, what did you do? This is a dumb idea.”

Definitely have team buy-in even if it’s under the radar team buy-in. I agree. You don’t want to be a lone wolf just doing things that could cause more harm than good.

In fact, to be clear, I think in that very code base I was in, part of the problem that was going on beforehand was that each developer was off doing their own thing and that was, actually, just compounding the problem.

Debbie: Great!

Ledge: Going cowboy, right? Yes. We’ve had situations where it’s like, no, code freeze really means code freeze. Stop checking things in because we’re going into production tomorrow.
We all understand that.

Well, I appreciate you both. We’ve gone for an hour here with really good learnings about legacy code. We will be putting this up on our site and sharing out all that stuff.

It’s super cool spending time with you. And the sales guy in me says that if there’s any way we shall do business together, you just let me know.

I appreciate the time. I’ll be sharing everything out and I hope we stay in touch.