Legacy Web Apps

Jamison Valenta (a Programmer at Tighten) joins us this week to dive deep into legacy apps - what to do if you've inherited one, how to know when to upgrade them, and a lot more.

Transcript

Dave Hicking:
Welcome to 20% Time, a podcast from the team at Tighten, a web development consultancy that specializes in Laravel, Vue, React, Live Wire, all kinds of stuff. My name's Dave Hicking and I'm here, as always, with my amazing co-host, Zuzana. How are you doing, Zuzana?

Zuzana Kunckova:
I'm doing okay. How are you doing, Dave?

Dave Hicking:
I'm doing fine. I'm doing fine. I'm very excited today because we are joined by somebody who is long overdue to be on this show, possibly I think he's the longest serving member of Tighten. I've made it sound like he's been in the armed services or something when I said that. Jamison, how are you doing?

Jamison Valenta:
I'm doing great, Dave.

Dave Hicking:
And Jamison, for folks who don't know you, who are you? What do you do? Who are you?

Jamison Valenta:
Well, you probably haven't necessarily ever heard of me because I'm just like one of those quiet, introverted programming people, but I've been with Tighten longer than anyone other than the bosses.

Dave Hicking:
Yeah, I knew that.

Jamison Valenta:
And Dan, I even beat Keith out in tenure.

Dave Hicking:
I know.

Jamison Valenta:
But yeah, I'm one of those people who does their work and loves their work and then goes and does a whole bunch of other things that aren't necessarily technology related.

Dave Hicking:
And that's great.

Zuzana Kunckova:
Think that's the way it should be.

Dave Hicking:
I think that's the way it should be. To each their own. Right, right. One of the things that we sometimes say around, I don't know, one of the things that Dan and I sometimes say, Matt as well say about Tighten when we're talking to potential clients is like nobody has seen more older code bases, older live code bases than Keith. Because often what Keith does where he takes a look at people's code bases. But hour for hour at Tighten, I don't know if anybody at Tighten has spent as much time in older code bases as you Jamison.

Jamison Valenta:
I don't think anyone can wave a stick at the MI plan.

Dave Hicking:
And you just wrote recently, I actually about a month now as we record, you wrote a really, really good and interesting blog post called Catching Up Laravel. And I wanted to have you on the show today to almost do a behind the scenes, maybe expound a little bit on parts of that and ask you some questions and kind of dive into that because this is something that Tighten gets asked about all the time. Devs always have to deal with, this sort of, okay, I've got this old thing, what do I do with it? And so I kind of want to dive in, if that's all right?

Jamison Valenta:
Absolutely.

Dave Hicking:
Okay. So I want to, let's start with first principles because words are tricky, which is one of my favorite sayings lately. What is legacy? So when someone says they've got a legacy app, how do you as a dev think about that term? How old is legacy? How old does it have to be to get to that point?

Jamison Valenta:
I think mostly what it does is it prompts me to ask the next question to the client. What do you mean by legacy? Because-

Dave Hicking:
Sure.

Jamison Valenta:
There's some-

Zuzana Kunckova:
You tell me.

Jamison Valenta:
Different assumptions there. Yeah, yeah. There's some assumptions. There could be some Perl stuff in there that we don't want to deal with, but most of the time when they end up hitting Tighten up for something like this, they're probably in the PHP space. So in that case, if someone is saying a legacy code base, I'm kind of assuming that it's been around for about a decade or more. In some cases that can be six years or more. But I think the true legacy ones are the ones that were written in the early PHP fives or lower, and then have evolved probably since then to newer versions of PHP, but probably got stuck somewhere.

Zuzana Kunckova:
Well, that's interesting. I mean, since you said you spent all this time working with legacy apps, have you always enjoyed working in this sort of projects? Or did it come about? And what do you find interesting about legacy? Maybe if I rephrase it, do you work with legacy by choice or is it that you always end up working with legacy whether you like it or not?

Jamison Valenta:
I think yes to both in some ways. But first I think it's important to understand that different people have different dispositions towards types of work. And the thing that I've really recognized about myself as a programmer, even when I was writing my first applications in a partnership duo, it always ended... It's realizing how quickly a person is excited about or is competent at learning new technology and how much they are capable of repeating work with incredible diligence.
And I fit more on the side of learning new technology is a little bit harder for me to focus down and figure out what I need to pull from docs or blog posts or whatever. But then, once I get a pattern in my head, my brain fairly happily repeats it forever without losing a lot of focus. So I'm a really diligent human being in general. So I think that really helps with a lot of the parts that most programmers burn out with working with legacy applications is that they need something new and shiny to keep them interested. And I find interest in the nuance of the somewhat repetitious nature that you find converting or upgrading old legacy apps.

Dave Hicking:
I bet there, I mean I imagine there are also might be a bit of, I don't know, intrigue or discovery to trying to unpack how did we get here. Trying to understand the code base and you get insight into, oh, they did this and everybody's got reasons, but I imagine that might be part of it as well.

Jamison Valenta:
Yeah, absolutely. It was certainly a thing I wanted to touch on during this podcast was that if you want to come from a more judgmental perspective of programmers who always do Greenfield work. So Greenfield, for anyone who doesn't know, is just brand new fresh application. There's a bunch of specifications and a client who's excited about doing the thing and you just work really hard to start from nothing and give them something that works. And with Greenfield work, you're so capable of, since there is no user base, there is no living, there's no application yet. There's no one that's expecting anything other than whatever you deliver. There's this capability of just going raised earth with anything that you do where, oh, we worked for a week on this thing and then the client decided that they actually don't want this thing, so we're just going to rip it out.
But in the context of a legacy application with an existing user base, you don't get to rip things out. I mean, sometimes you do and you-

Dave Hicking:
Sometimes really.

Jamison Valenta:
And when you do, it feels amazing. But there's a whole bunch of due diligence work that you have to do coming up to that to make sure that any data that you need out of that, the users are notified that the... Man, the list is endless regarding the things that you need to make sure before you get this glory moment of the deleting five files or 2000 lines of code.
But in the context of just being able to acknowledge the fact that legacy applications are living beasts that have existed for a long time, they almost always lack tests. So the application is the ones true source of what it does. And digging through ever so carefully to kind of suss out what needs to change as I'm literally making little pawing motions as I'm gently pushing dirt around-

Dave Hicking:
Gentle.

Jamison Valenta:
Because there's some, the ways that we used to write PHP code, especially back in procedural PHP code days before we got even into MVC, there's just some functions and things and ways of doing array data manipulation that is inscrutable, inscrutable, inscrutable.

Dave Hicking:
Inscrutable.

Jamison Valenta:
Inscrutable. And you kind of have to figure out a way to leave it the way it is unless you can get an absolute definition from the client or figure it out for yourself to make sure that that method behaves the same way. Because the worst thing that you can do is upgrade some code but then miss out on some important bits of business logic that have worked for five or 10 years that's going to cause some client to be upset.

Dave Hicking:
I wanted to touch on this idea of, okay, so you've got something, maybe it's old, maybe it's legacy, maybe it's whatever, but it works and it runs and it's often, Jamison, like you just said, it does some sort of very important core, whether it's a backend office operation or whatever it is, it's super important. And so sometimes there's the sort of question of, well, what if we did this? What if we built on it? What if we tried to go in and add things? As opposed to actually, you don't want to touch this except to make sure that you're only touching what you have confidence that you won't break. You know what I mean? And sometimes I know at Tighten that comes down to the simple question of are there tests? Can we actually prove that what we're going to do is going to work? But how do you approach that?

Jamison Valenta:
Okay, let's break that down.

Dave Hicking:
Sure.

Jamison Valenta:
To a couple of different questions.

Dave Hicking:
Or to ramble the question.

Jamison Valenta:
So the first question I think that I want to answer is how do you decide if an application should not be touched? If it should just exist in its form until everything dies. And I think my first and primary concern there is security. And you can achieve security in a handful of different ways. But if you're running an little internal application that doesn't have access to the Internet, security fixes matter a whole lot less, especially, or if the application houses data that isn't secure. Doesn't need to be secure. If it is hacked, no one cares. Then that's in a whole nother interesting reason for not caring about security as much.
But mostly I know a lot of companies out there have intranets, and if applications only live on intranets, your security concerns can be a lot smaller than if it's open to the Internet. And if the domain is available to the public web. If it is available to the public web, then my question is it up to date? As in, is PHP up to date? Is my SQL in a reasonable shape? And anything that's blocking, or your JavaScript dependencies, capable of being up to date? And if the answer is no, because all of your software packages have been abandoned five years ago, you should, you're existing in a state that will eventually be compromised.

Dave Hicking:
Yeah, it'll catch up to you at some point.

Jamison Valenta:
And it could be fine for another five years and then you lose, all of your data is compromised, or your server, your site goes down. It could be fine, but it might not be. My I'm a little bit into beekeeping and there this, I know it became pretty popular a number of years ago when beehives all over the country started collapsing, colony collapse disorder, primarily caused by varroa mite infestation, which this animal exists in the world, but then it spread. And basically, some people opt to track the might populations in their hives and other people opted to not. And a couple months ago, we had a presenter that was a specialist in varroa mite, she was talking about how it was. And there was one cautionary tale from one beekeeper who said, "Yeah, I went 15 years. I never did a single mite check, I never lost a single hive. And then one year, I lost every one of my 25 hives." So anecdotal perspective in we haven't been compromised, compromised yet, is not necessarily a safe way to approach things.

Zuzana Kunckova:
Just because it hasn't happened yet, it might be just around a corner.

Jamison Valenta:
It could be.

Zuzana Kunckova:
Well you mentioned security, which is a big thing, but have you ever heard about any reasons that you don't think like that, not saying bad, but maybe misguided reasons why people want to upgrade an existing running up?

Jamison Valenta:
I would say one of the most difficult types of upgrading work, which is not exactly answering your question, but we'll see how if we get there. The most difficult way, type of project to be on is when a client would approach us and say, "Hey, there is this existing application that does all of these things. It is written in this PHP framework. We want it to exist to be in Laravel, and we want it to do exactly what it did before."

Zuzana Kunckova:
So it just changed the framework for whatever reason, not necessarily security or because their existing application is outdated? They just want to switch frameworks.

Jamison Valenta:
Or maybe their security is an important part of their desire to upgrade. Or there is certainly a bigger feature set or a more user developer friendly code base associated with Laravel. But the key challenge here is make the same thing exactly as it is works right now.
Can you tell I'm speaking from experience?

Zuzana Kunckova:
Yeah.

Dave Hicking:
Well, I was going to ask how much does that scare you? But I mean maybe more broadly for the folks who are listening, how much should that scare another developer who might be listening to this? Or somebody who's not a developer and they have this app and they want to ask somebody to do that for them maybe.

Jamison Valenta:
Yeah. So in the process of upgrading a legacy app, whether you are changing frameworks or anything, the thing that you really need to be careful about is that if you are starting from scratch, there's all of, again, those little bits and pieces of business logic that exist in the code that a function looks like it does this thing, but it actually does this other thing and a really specific case and can be really hard to identify when that thing is happening. So if you're going to recode that from scratch, you start losing all of these bits of information, which you don't really come out until QA happens.
And then once QA pulls it out, then you will, there's some architecture of the application that you ended up needed to be doing, and then it adds another day, or it adds another two days or two weeks. So any sort of contact, any sort of situation where an existing application is running and you have to duplicate on everything, then you're going to run into a menagerie of lost business logic. And then, it's going to pop up at inconvenient times. And it's almost certainly going to extend any bid or scope that you could possibly give to the client and on the outset.

Zuzana Kunckova:
You mentioned in your blog post on the Tighten website that actually some smaller application might be worth rewriting from scratch rather than trying to upgrade. So when would you then decide, I mean, I think you mentioned that anything that's smaller about 25 routes or what 25 controllers you would consider rewriting rather than upgrading. So why, again, speaking from experience, I guess.

Jamison Valenta:
So there's most of the time if an application is less than 25 routes, which means it's going to be several entities in the database, probably, the application itself is a lot easier to overall get into your brain and kind of suss out what it does, what it doesn't do. And depending on that situation, even if the application is written in Laravel, but if it's in early fives Laravel, even going through, we often use Laravel shift internally and for clients.

Dave Hicking:
Sure.

Jamison Valenta:
Going through 10 Laravel shifts can take a long time. And at the end, you still have to have a lot of working knowledge of exactly how Laravel, now nine, is structured, which is very different in some ways than Laravel 5.1. And so even though Laravel shift will get you a lot of the way to what is considered a modern development, sorry, directory structure, it's still going to leave some stuff here and there. And so it's going to, not going to be, it doesn't allow Laravel to be example to you, the developer, on how we are going to be doing it from here on up.
So it can, and then also once you do get it up to Laravel, whatever the latest version is, it will end up being a lot easier to continue doing Laravel upgrades from that point out. Because Laravel, as an ecosystem and as an application framework, is a lot more settled than it was back in the early fives. So if you have a small number of routes, extracting individual controller methods out and putting them into a fresh Laravel application can probably save you some time. And it also results in you having a very fresh, shiny directory structure, middle layers, et cetera without having to remember as an individual developer how these changed from 5.1 to 5.5 and then from 5.5 to six, and then from six to nine, which are places where there are significant changes to the under wiring of Laravel.

Zuzana Kunckova:
Have you ever started upgrading an application or a legacy app and then decided actually scrap it, I'm just going to rebuild it from scratch?

Jamison Valenta:
Yep.

Zuzana Kunckova:
Okay. Often?

Jamison Valenta:
Yeah. So there was a while there, a couple years, where all of my projects at Tighten were in the sort of Laravel 5.3 to Laravel 5.5 realm. And because of that, I didn't really know, or it wasn't ingrained knowledge where Laravel seven or eight at the time, how it was structured. So rather than going through, I started doing the upgrade process, but I didn't really know where I was going because I wasn't familiar with the way that Laravel was now. So I started doing the work, got pretty confused and frustrated because some things had changed where they were working and the hacks that I had been made making on Middlewares, et cetera in 5.2 were just broken. And so suddenly my application wasn't working after doing a shift or two and in a way that I couldn't immediately fix because I didn't understand where Laravel worked, how it was expecting me to do this thing now.
So at that point in time, after, I don't know, maybe 10 or 20 hours of work, I was just like, nope, we're going to start over. So what I did is I started up a brand new Laravel application and then ran them side by side, figured out what authentication packages, which were now available that weren't available then, and shifted things over piece by piece by having the two applications side by side. But since the application was only a limited number of routes, that was a lot more achievable than if I were doing all of that piecemeal shifting over with a hundred route or a 200 route, which is basically, you can't do it at once. It's impossible. At least not one person. Maybe if you had a team.

Dave Hicking:
I want to go back real quick to the, you were talking about how if you're trying to rewrite something, business logic is tied up in bits that you may not understand in the old app and when you don't really discover it until you get to the QA portion. And I think one thing that happens sometimes when you try to either, call it a significant update or rewrite or something more than just sort of piecemeal, is it can take a long time for that new work to get to a place where people often feel comfortable shipping it. So you build this whole thing up and you get down this whole path and nobody outside of the dev team has, I mean, you might have done some demos, you might have shown it up, but nobody's really gotten into it. And then of course you run into problems. When it comes to doing this sort of thing, is the answer just to try to start small and ship as often as humanly possible, so that you can get that feedback?

Jamison Valenta:
Yeah. But that's-

Dave Hicking:
A loaded.

Jamison Valenta:
Yeah, I love it. The challenge with, and I kind of tried to outlaw outline that in my blog post, which is basically saying-

Dave Hicking:
Little wins. I think you have this whole section on it, right?

Jamison Valenta:
Yeah. The little wins and deciding where your big break points of work deliverables are going to be. And you can only figure that out based upon what bits of security need to be up, what of your packages, what of your PHP need to get to be upgraded. How far can we push PHP up before we start running into, oh, all of these function calls are no longer valid, but the behavior is different, so now we have to bring in a helper function or it makes one of our really old packages not able to work anymore. So figuring out what your first step is to get PHP forward, what's your first step is to get your packages up to something that is close to or currently supported. And then pulling everything forward that needs to get pulled forward from that first big step and then calling it good. And that may not be the thing that the client wants at finish, but at least it's one pull request.
Then as you're going, sometimes you run into situations where there's an old bit of code that is bad and we don't want it to continue to survive, or there it's a feature that was going to be ripped out or modified anyway, then that's a good opportunity to be like, okay, we can work on this. We're going to write it in as modern of a way as we possibly can with the constraints of how much we're upgrading PHP and Laravel on this pull request. And so the client gets a new feature or an upgraded feature, but you're not, and you're not pulling up code that you're going to change anyway. And so you can offer that as this is a thing that we can give you, but I wouldn't generally recommend doing it in that way unless it just doesn't want to move up with you anyway. If you have to ditch it, you might as well rewrite it in the way that the client wants. And if you don't have to ditch it, I would say just push it off a little bit longer if you can.

Dave Hicking:
Sure.

Jamison Valenta:
And then of course the client is going to give you feedback and no, this feature, this tool absolutely needs to be updated. And then you have to throw it in and okay, that's fine. But I think the key component here is that so many of these one or two or three PRs that will happen in a legacy application upgrade from old Laravel to new Laravel, or from just barely got into a Laravel container of an old procedural PHP app to something that looks more recognizably Laravel, those upgrades, if you're working with a small team, can take months, half a month, a year. So trying to keep those as a lightweight as possible is an ongoing goal, desire-

Zuzana Kunckova:
Struggle of a thing.

Jamison Valenta:
Struggle. Yeah. Because I'm like, end of the day, the sooner we can get that first PR out, the better it is for the client. So even if the client feels like I'm pushing back at them, I'm still working to what I feel is their best long-term interest.

Dave Hicking:
And I think the better it is for the devs on the team as well. Right? Because it sometimes is, I'm going to say scary, we'll say sometimes it's scary to get that first if it feels like it's too early, right? Because you're like, oh, this works not ready yet. It's like, well, it's got to go at some point.

Zuzana Kunckova:
Well, we know as devs that how important it is to, sometimes you need to upgrade your application. But sometimes there might be a little bit of pushback from the marketing or the product team that will say, "Well actually it's working just fine. And why do we have to invest all this time and money into something that's working?" What would you say to that? What would you say to them?

Jamison Valenta:
There? I think there are two things. There's one, the beehive varroa mite analogy, which is even if it is working totally fine, but it's running old PHP, it's running on an old outdated server. There's a security issue there. There's also an issue that I haven't touched on yet, which is your ability to spin up new environments, in that once you get to a certain age of Ubuntu, once you get to a certain age of PHP, if you live in a provisioned environment, server environments, there's a point in time when a service won't be able to spin up your PHP 5.3 anymore. So if for whatever reason your server falls over, which just happens sometimes, and you need to go and need to start and spin up a replacement production server. So you're assuming no data loss, there's no security breach, it's just your server got tired and died.
And it could be because it's living on some cloud service. It could be because it's in one of your employees closets. And if you don't have a way to spin up that environment again quickly, that's application downtime. That dramatically erodes your customer confidence, especially if it happens more than once in any amount of time. Like once a year if your servers fall over, I don't know, it's probably going to be rough. So just because it is there and it works, you need to be able to think about like, oh, do I have a server that just lives that can be either is the same power as my production server or can be quickly upgraded to power of my production server that if production falls over, I can push that database data over to that fallback server and get right back up again.
If you can still do that and the application's old, cool, great. But if you can't, that's also a smell for if you can't build those environments, you need to figure out, you need to get to a point where you can start building those environments more rapidly and more consistently. We had one client once who, there was one person, one administrator who was in charge of all things. Actually now wasn't one client, it was many clients.

Dave Hicking:
Well, I think that's not even just client. I think it's sort of sometimes still true of many places. There's the one person-

Jamison Valenta:
And that one person happens to know from memory how to build and provision a new server to do the things that needs to be done. If that person becomes disgruntled, if that person gets sick, if that person just disappears off the planet because they're on some beach someplace, and you run into a problem, then you kind of end up in a situation again, how do you move forward? And so-

Zuzana Kunckova:
Then you have a problem.

Jamison Valenta:
There's going to be a big fire eventually.

Dave Hicking:
Yeah. I think that's just in general true. One of the things that I think we always try to help our clients do is make it so that pushing to prod is, nevermind not scary, but it's just routine and is very doable and is as automated as possible. Part of what builds up, I think with when you're dealing with, because oftentimes a legacy app also come along with a legacy infrastructure, not always, but sometimes that comes along with it and there's just like, well, we haven't made this upgrade yet because updating it or pushing live is a big deal. And then all of a sudden, well there becomes a barrier of, well, we can only do things that are important enough to justify a big push. And it's like, no, no, no, we got to tear all that down and have it. So it's just once it's been tested, you can just make it live, it's okay. Nothing will break. That's the goal anyway.

Jamison Valenta:
And a really good way to move from that it's a big deal to a not big deal without sacrificing the integrity of production deployment processes that already exist is saying, okay, products exists over here, it's fine, it's great. What we're going to start doing is we're going to add a sandbox environment or a staging environment. And so first that gives them an opportunity to figure out how to make production again, because in this case the staging environment should be almost exactly production.
It may cost a fair amount of money, but it's worth it. Or we can down some parts of staging that aren't important, but it should be almost the same environment, even if it's not the same 32 core 600 terabyte drives. But as they start provisioning and building that staging, or sorry, I keep on misspeaking, as they continue to build that staging environment, they will learn things that they didn't remember about their production environment, how to build it, et cetera. And then as we start building our deployment processes to automate, like adding continuous integration that runs tests, building scripts that push and pull the right things to the right places, because often these older server architectures don't follow a traditional forge server. So sometimes files and directories need to get copied and moved around.
We're turning like information from that exist in employees' heads and random scripts distributed around into deployment scripts. So those scripts become documentation as to how these things live. And then once both we have, and also the client has gotten used to getting the staging working and it feels like that process is working smoothly, then they have a whole lot more confidence to switch over production's deployment systems to that. So at that point in time, you turn a switch.
Most of the time the best way to do is to actually move production to retire and just hold production as it is, and then point all the new traffic into the staging environment, make this your new production. And then, if something goes terribly, terribly wrong, you still have your old monolith intact that you can fall back to some degree. Of course, there's always complications with falling back once you've been living in a different environment. But then you spin up a new staging server and then formally retire your original legacy server, and then you're in a space where you can actually start deploying again in a way that doesn't feel like this onerous burden.

Dave Hicking:
Okay. So if someone's listening to this and they're a dev who has inherited in some way a legacy app, aside from reading your excellent blog post, do you have any do's or don'ts or maybe first things that people should keep in mind as they are looking at this wonderful gift that they have been handed?

Zuzana Kunckova:
Breathe. First of all, breathe.

Jamison Valenta:
Yeah, no, I completely agree with Zuzana. One thing, especially if you as a developer have always been on younger applications and you are gifted an old one, you need to remember or you to feel empowered to say, wait, this is going... The pacing of working in older applications is much slower than moving in newer applications, but within new feature development as well as making a single change, especially as you're trying to figure suss out from the application where a thing lives when a stakeholder is saying, "Oh, I need this button to do this other thing" or "We need to add or change some text." It's possible that that button lives in four different places and it's duplicated for different kinds of users. And that actually may make sense in the context of that application. It might be the right choice. But you're not necessarily going to know that from the outset unless you have inherited an application that's very old and also really well documented, which it's, there's no way that happens. So-

Dave Hicking:
Those are rare beasts.

Jamison Valenta:
Or just rare components that you'll run into. Yes, because one developer had to change it a thousand times and which was like, man, I forget about how to do this every time. So I'm just going to write this into code and a little comment that says, if you change it in this file, change it in these other files. I've done that to myself.

Zuzana Kunckova:
But I really like when I read your post, and you mentioned that you kind of reframe errors as your friends, not your enemies. I think exactly the thing you said that... Errors are a guide to pass forward, not the bane of your existence. So for me personally, they're still kind of not friends. I wouldn't go as my friends, they're a little bit scary still. So have you always felt this way or is it something you get to eventually... How do you reframe this? How would you start looking at errors? I think for me it would help if they weren't red. I think the red color, when you think the output in the terminal, everything is red. I think that already makes me feel really anxious. So maybe we could start there. But other than the color, how would you tell me? How do I reframe my relationship with errors? Please help.

Jamison Valenta:
All right, so maybe it'll help if I frame it in the context of the alternative, which is you have a legacy application that doesn't have a single test and you need to make an upgrade and you don't really know the application super well. Or it has 3, 4, 500 routes, dozens of controllers, and some smatterings of legacy code in there. So there's some stuff that just won't ever have tests until it gets kind of put into a more Laravel context or it gets unit tested or whatever. But then you can't even, you do the upgrade, you open up the web browser to go to the place, and there's just this error. And there's nothing you can do. There's no, you just got to go and you got to fix that error and then you go back to your browser and you refresh the page. And this happens, especially on the first go when you just did an upgrade. You might spend a week just trying to get that first page to load.
Whereas if you do have tests, you're going to have probably some integration tests. So making HTTP calls and being able to assert a certain user is able to access a certain resource. And those inner pages tend to be a little bit more forgiving because they're not doing that initial authentication and redirecting that user according to their user state or whatever. But all those errors are telling me specific code paths that don't work, rather than just this blaring message of the application is broken.
And so I tend to be able to get past the initial application is broken when tests are erroring at me, but in the context of the big main screen errors, it can take a lot longer because there's more things you have to get through. So I would say errors are friends because it means that I don't have to think and remember the business logic to be able to trigger off these various state changes in the application or in the database. And then once I do fix that, and then I go and I change and try to fix some other test and then I go and break that other thing, the original thing, it tells me that I broke it again, which is way better than me having to remember this massive QA process for myself and do that 100, 200, 300 times over the course of several months. I'm going to miss something. The, it's a simple answer is tests help me not miss as many things. So they are my friends.

Zuzana Kunckova:
I'll try to remember that next time I see an error.

Jamison Valenta:
And when the next time you're writing test-

Zuzana Kunckova:
Said it's fine-

Jamison Valenta:
I'm making a friend, I'm literally writing a friend right now.

Zuzana Kunckova:
So it's for the future Zuzana, even though now I'm hating it. Not always. Sometimes. But next week Zuzana is going to thank me. So yeah, I don't know. I don't think I'm there yet with the friends, but I can see the path forward I suppose.

Jamison Valenta:
I definitely enjoy reframing my myself as different versions of myself being past Jamison, way past Jamison, and future Jamison. Like me writing a test is for future Jamison's benefit, even though I hate my life right now. Just I really don't want to write another one of these tests for this specific user on this edge case that may or may not ever matter. And there are also times when I get to thank past Jamison and there's other times when I get to curse past Jamison because I was being lazy. And if you live in a code base long enough, you will definitely have those situations where you're like, oh man, what were you doing? But recognizing them as separate selves as opposed to your current self will make you not necessarily feel... So it will help check the sort of negative feel like self feels that can exist as a programmer.

Zuzana Kunckova:
Yeah, I mean this is totally not on topic, but it definitely helps me deal with anxiety, anything else. Every time I kind of have the feel that I need to be upset at myself for doing something, I gave that person a different name. So it's not me. I don't know, it sounds probably crazy, but it's much easier to have two different people so that the nasty voices have in your head that tell you you're not good enough or you're not doing well enough and you suck, this is, you give it that voice a name, and it's much easier to then tell that name to go away rather than saying, oh, it's me saying that to myself. So I definitely see the value in having different personas. Past, future, and the current Zuzana. And then there's this nasty one that I'm not going to name that every now and then just airs its head, evil head and tells me that I can't do stuff, but it's definitely useless. Yeah, useful. Sorry. Yeah.

Dave Hicking:
So Jamison, that's actually the end of all of our questions, but before we go, I want to ask you, is there one thing that you wish we had a chance to talk about that we didn't talk about today?

Jamison Valenta:
Yes, but I also don't know how to frame it in a way that is concise, but let me try.

Dave Hicking:
Sure, go for it.

Jamison Valenta:
The idea is about testing, and I kind of want to write a post about it, but I still am very concerned about not getting the breadth and the depth to the right level. But basically it's the idea of when you come from an application or a route or whatever that isn't tested at all, and how do you approach, make those first steps to converting that into modern code structure, easier to read, pulling out that old procedural PHP stuff with all the hidden business logic? How do you do that? And what's the most effective way to ensure that you're not dropping business logic as you convert a legacy app into something that is more modern? And it's the thing I do a lot, but the painful, challenging part is that each time I do it, there's kind of a different approach because it's very situationally dependent. But the sort of balance between starting with some unit tests, extracting some logic into a plain old PHP class, or making some initial assertions as an integration HTTP class.
And then slowly starting from the very most outset of assertion that you can to the most detailed unit test assertion that you can. And then slowly add tests to fill in the middle bits until you have actual code coverage. And then once you have actual code coverage, then you can start saying, oh, well this weird function that I extracted is challenging and it is written in a way that is really hard to update, but we have it tested, we know what its output should be. So we're going to pull that out and we're going to rewrite that in something that is more developer friendly. And then once that's written in a nicer way, we can start thinking about like, oh, should this method actually return the thing that's returning? Is that helpful for the front end? And be like, oh, actually the front end would this shaped us thing.
So then we're saying, okay, so if we know that we can assert that the front end wants this shaped of thing and we have all of this business logic here, how do we then change our unit tests to match that function, return signature and make that nicer? And so this kind of wobble to, from the integration side to the unit test side, will help you move from super old code that is probably returning HTML from a function as you go in Vue to something that looks much more like modern Laravel. And yeah, I don't know how to write it, but I think it will be good or interesting if I do manage that.

Zuzana Kunckova:
Yeah.

Dave Hicking:
Yeah, you should.

Zuzana Kunckova:
I think this is all about, it's a whole big balancing act. I mean, listening to you, anything to do with legacy, it's very walking a fine line between doing just enough to upgrade without breaking it. You don't want to steer either way, just right in the middle. And now what you said is about, it's all about balancing, knowing where the line is so you don't steer in any direction way too much.

Jamison Valenta:
And fundamentally, it's a perspective of how do you have the long term perspective of maintaining, nurturing a living application versus considering deliverables. And to me that makes a lot of sense. And to other people it might make a little bit less sense, but just it feels good to get an application one step further down the line for me, even if it's not anywhere close to where you want it to be or anywhere close to friendly to a new programmer yet. But it could be someday, maybe.

Zuzana Kunckova:
Yeah, I like that. And like you said, it might not be you working on it a year down the line, it will be another developer and then kind of paying it forward. You want to think whatever you do with application, you don't want it to again, be in a state where somebody else will look at it and not know what to do with it. So whatever you do, a little step you make or you take, let's make it better than what it was yesterday.

Jamison Valenta:
Good words to live by and code by, I think.

Zuzana Kunckova:
Yeah.

Dave Hicking:
And a good way to end this episode, I think. Jamison, thank you so much for joining us. I'll link to the blog post that we've been talking about in the notes, so if you haven't read it yet, just whatever podcast app you're using to listen to this, you should see a link there. Jamison, is there any other place people should go to find your stuff online?

Jamison Valenta:
Honestly, I don't have a huge online presence. So yeah, go to Tighten. Eventually will add my contributions to the Tighten website and it'll be great.

Dave Hicking:
We do need to update your, when you click so inside website, when you click on someone's photo-

Jamison Valenta:
This will request up for it.

Dave Hicking:
Okay, good. I was going to say, yeah, yeah.

Jamison Valenta:
I did. I had to get my-

Dave Hicking:
We should get that approved. Sure. I'm sure I nobody to talk to you to get that done. Yep. All right. Yeah, I think that's it. Thank you so much, Jamison. Appreciate it, Zuzana. Thank you as always. And thanks everybody for listening.

Zuzana Kunckova:
Thank you.

Jamison Valenta:
Thanks.

Zuzana Kunckova:
Yep. Bye.