Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:15):
Last episode, we were talking about Legacy Codebases and how we approach bug reporting. And this episode, I thought it might be nice to kind of maybe view this as a continuation of that discussion. You know, the higher level concept of inheriting a Legacy Codebase but more from the aspect of organization of the code. And I guess what I'm thinking of is kind of a couple different dimensions. So there's the file and folder structure, and then maybe there's the internal structure of the code itself. Like how things are grouped into services or classes or different things like that. I have a project or two in mind, Aaron, we worked on together where we had to walk this balancing beam of not going too far, but also having to make it slowly better. So I'll kind of use that as a jumping-off point and I'll let you react to it.

Aaron Saray (01:09):
Okay.

Joel Clermont (01:09):
Let's picture you just inherited a code base and I'm going to pick an example of a Legacy Code base, again, we won't name names, but we worked on together. And I would call this where the old school traditional PHP, no framework, right?

Aaron Saray (01:28):
Okay.

Joel Clermont (01:28):
No framework at all. So kind of having that project in mind when we opened it up, some of the things we found, everything pretty much in the public directory. For some reason folders symlinked into other folders and it became unclear if this code was duplicated or things like that. So what goes to your mind-

Aaron Saray (01:49):
Sometimes files were even linked themselves, hard linked.

Joel Clermont (01:52):
Right, individual files?

Aaron Saray (01:54):
Mm-hmm (affirmative).

Joel Clermont (01:54):
So what went through your mind when...? Because we knew that had to be improved for multiple valid reasons. But what was the thought process you had when you looked at the first time on how to tackle making it better?

Aaron Saray (02:07):
Well, I think one of the things I thought about when I first saw that was that... Well, I'll be honest, first thing I thought was, "Ah, I hate all this," right?

Joel Clermont (02:14):
Well, yes.

Aaron Saray (02:15):
Let's be honest. I opened like, "Ah, what is this?" But the first thing I did is I left it alone and I did a couple bug fixes. Because I figured it's probably... I mean, I'm not going to sugarcoat it for today's episode. It's probably all garbage but let me just try to work in a little bit just to make sure that I'm not wrong. I mean, if we fast forward to the end I wasn't wrong it was all garbage we were working on to get better. But along the lines you have to kind of figure out what is specifically garbage about it. Why does this "suck"? And I can think of the first example I ran into is that we had something we had to change and the IDE couldn't even make sense of stuff because it was just like old school, everything was all mixed up. So I did a search and ended up find where all the instances of this sort of concept are and it came up with like 16 results. I go into the first one and I change the stuff and...
Now I'm making a mental picture in my head. This is important is, we kind of talked about this before. It's not time to change the structure it's time to develop the understanding of what you're in. Because I think sometimes we like to think that everyone thinks like, "Oh, that developer before me was an idiot". Well, I mean, sure, but really they had a thought process and it's probably not written down so it's probably going to save you a lot of time if you just kind of remove that bias just for a little bit, you can let it come roaring back later. Remove it for a little bit-

Joel Clermont (03:47):
Yeah, it's not productive.

Aaron Saray (03:48):
Yea. And just kind of see if you can pick up on what they were thinking. So that was kind of my thought is, I'm going to try to pick up on what this person was thinking. So I go and edited the first place, I open it in the second place and it's not there. I'm like, "But it literally found it." Then I realize, "Oh, the second result was a symlinked version of the first one." And I'm like, "Oh, okay, so that must mean all the ones below that are probably duplicates." And I'm like, "Nope." Some of those were like in the symlink folder then there was a real file and stuff. So that whole first exercise though kind of put me in the mindset of, "I haven't yet thought of a pattern or there isn't a pattern for whether a whole folder is symlinked, just a file or a mix." So I then know that I have to kind of check these things and even know that some might go away in the middle because they're linked. I can't make an assumption about that.

Joel Clermont (04:48):
Yeah. There's kind of two points I picked up on there as you were talking. One is one of the benefits of not just diving in and changing things is because there were surprises. So even just like a very simple refactoring or bug fix or whatever, revealed to you the surprises about the symlinks and yet not everything was a symlink. The other point I thought was kind of interesting too is like getting into the mindset of the developer. It made me think of like a crime show on TV where they have the psychological profiler come in and they're like, "To catch this guy we got to get into his mindset." But that's valuable too because even if you don't agree with that, if you can actually figure out why did they symlink this instead of copying it, it sort of helps you unwind it better because you at least have an understanding maybe of why it was done in the first place.

Aaron Saray (05:42):
Yeah, a very good point. As we're looking through then some of that, I think you're looking at the project at the same time from a different aspect, some different changes and stuff. We started getting a better idea of kind of how it was put together and then I think we came up with a really interesting conversation halfway through. We were kind of doing maintenance and kind of taking over for another developer that just disappeared. And I remember you asking like, "Should we just replace this back-end with Laravel and keep their front-end?" Because the front-end was a whole other beast.

Joel Clermont (06:17):
Oh boy.

Aaron Saray (06:17):
It was in a language that was popular 13 years ago. There was a lot to unwind there and you said, "Maybe we should just start replacing the back-end with the front-end or with Laravel." And I'd tell you I really kind of wanted to but I said, "You know, I don't think we should because there's still enough that we haven't figured out here. There's a lot of code duplication and we just need to know this a little bit better and maybe in the future we'll pose like a larger right. But now we still have too many things and I'm not sure if all of them are in use. So I don't know if it's worth almost a system of having two back-ends in a way."

Joel Clermont (07:02):
Exactly, yeah. It just was too early at the time. I'm going to shift gears a little bit because you know that's certainly one style of project we've inherited the lack of organization or the bewildering organization. But there's another kind that I've seen more than once and it's like the overly organized. So what I mean by that is like, for example, a Laravel app, when you install a fresh Laravel app there's certain conventions. If things go in certain places maybe you even use a models folder, you do a couple really basic things in addition to what the default out of the box convention is. And you kind of expect things to sort of exist in a top level app folder and subfolders underneath it. But there are different schools of thought and-

Aaron Saray (07:46):
I was going to say. I can tell you're old school already because you said maybe you even use a model folder as if that's not what happens now.

Joel Clermont (07:53):
Yeah, that's true. That is the default now, isn't it? Yeah.

Aaron Saray (07:55):
Yeah.

Joel Clermont (07:55):
Well, I was very-

Aaron Saray (07:55):
It used to not be.

Joel Clermont (07:58):
Yeah. But there's other ways of organizing apps and I don't want to necessarily get into the argument of whether those are right or wrong because it is contextual. But let's just think of a particular project we inherited where it was completely outside of the normal Laravel conventions. It worked but so much wrangling was done in service providers and making things work in this kind of alternate structure that it bothered me. Like, "Why would you do this?" And I want to change it back to the default but that was like a... So that's kind of the other end of the extreme, right? Is where it certainly has organization but it's just very different from what you would expect or from what the convention is for the framework you're working in, in our case Laravel. How would you tackle that, Aaron? Like, is it the same sort of process as the under organized one or any additional insights on how to tackle something like that?

Aaron Saray (08:57):
Yeah, I think it's the same sort of process where you have to understand why these are in that area, what orders things happen. In that particular project I even remember firing up Xdebug and walking through and figuring out what order all these different service providers go. Because there was some matching and logic inside of the service providers in a strange way that would or would not load other ones. So there was a lot of challenge there but I think, again, it just comes to take a few beats to understand what's actually happening here before you just kind of tear it down. And, again, I think it comes down to the fact that you have to understand and comprehend that you're going to maybe hate this and you got to put that to the side for a little while. I mean, that kind of goes along the same lines of, "Why did this person do this? Why did this team do this overly complex thing?" Which was well because they thought they were going to do it better than what was already out there. That's fine, except for are you solving a business problem or are you doing computer science work? Because there's a point to doing things "a good way and the right way" best practices but when you're starting to re-architect how everything works inside of another tool set, then that's almost an arrogance in a way I think sometimes. Because you're like, "Well, I know better than the 13,000 people that put this together."

Joel Clermont (10:32):
Right. I think the mindset maybe, if I had to guess, is like, "I have too much time on my hands so let's experiment with different ways." And to be fair if I remember correctly, it was in an earlier version of Laravel, maybe it was like early Version 5 or something.

Aaron Saray (10:51):
It was in the 4 and then it was upgraded to 5. So there was a lot of legacy back and forth there too and stuff.

Joel Clermont (10:58):
Yeah. And there were even things that did not exist in the framework that they kind of bolted in. To the mind it's like, "Oh this is stupid." Now when I look at it in the modern age and I'm like, "Well, why don't you just use this built-in feature?" Well that feature didn't exist when they wrote this so that was another thing too. And working through that... because I think I probably spent, at least toward the tail end, more time in that codebase\ than you. I just kind of pick battles and it's like, "Okay, is this something that I could pretty easily remove a bunch of code and use a built-in Laravel feature?" Then great, I'll do it. If not, like you said, just kind of live with it and don't invest weeks or months in trying to make something back to the convention just because it's what suits you. I like the point about the business case too because that's another thing, especially when you're brand new to a project. They hired you for a reason and it probably wasn't to reorganize the code, right? There are other reasons so that's another very valid point to not jump into that too soon. Not only is it less effective but it's less valuable to the client at that early stage in the time you're working with them on it.

Aaron Saray (12:11):
II think a lot of times we think, "Well, if I just reorganize the code and get it to where I want it I'll be much faster." Which is probably wrong and the reason for that is because... I don't know about you, Joel, but when I estimate the amount of time something's going to take me to do, especially like refactoring, I'll always spot on. Never takes longer than I expect, right?

Joel Clermont (12:32):
Same here. Some times less time.

Aaron Saray (12:34):
Right. So you end up... Yeah, right. So you end up, you end up spending more time than even what you predicted getting it back, getting into a state that nothing happens. And possibly you might have introduced some bugs along the way because you didn't understand all of this. So there's a lot you have to hold back on with that as well.

Joel Clermont (12:54):
So to summarize this whole episode, when you first open up that codebase just take a deep breath, it's going to be okay. You can fix that later but don't start tearing it apart on day one.

Aaron Saray (13:07):
Yep.
So I've been doing Zoom video calls because I've been working remote much longer than a lot of people have, right?

Joel Clermont (13:19):
You did it before it was cool.

Aaron Saray (13:21):
Yeah, I did. Yeah, I was... "Oh, just that's the story of my life." I did it before it was cool and sometimes it still isn't cool the things I do. But I've always been interested in what's behind the people. So I remember a lot of times me and you when we first started talking I would ask you all about the different things behind you. I'm looking at your office space here and I'm like, "Oh, there's a bunch of interesting things." And then there's a shaver.

Joel Clermont (13:50):
Yep.

Aaron Saray (13:51):
Which I find really weird.

Joel Clermont (13:52):
You can only see the shaver if I move my head to the side, so it kind of reveals itself occasionally.

Aaron Saray (14:00):
You know, I thought about that when I'm doing my calls and I wanted to be a little bit more professional. So for this longest time I went and did research on like, "Oh," I like those people that have like those really nice wood walls behind them. So I looked up all the different places you can buy wood. I'm in an apartment right now and I was like, "Boy, I don't want to screw stuff into the wall so it has to be like maybe stick on." And man, those are all really expensive and they're like, "Oh, you have to sand this wall so you can stick it on." I'm like, "What?" Like, I don't want to take these off and the landlord will be like, "Why is there just a big white patch?"
So I'm trying to figure out these different things and then I'm like, "Well, maybe I can get a room divider to put behind me." And all the room dividers are usually like four or five panels and just a placement on my desk and everything and that's just a little too small. So I was searching around and I finally found a room divider that has like six panels, so I put it up behind me and that's what you can see now when we do our video calls. And I thought everything was going good, I thought it looked nice. Until one person on one of our calls goes, "Aaron, are you in a sauna?"

Joel Clermont (15:09):
Yeah, it kind of has that look.

Aaron Saray (15:13):
Like, I even hung lights on it and stuff, which-

Joel Clermont (15:15):
Yeah, you wouldn't do that toe sauna.

Aaron Saray (15:17):
... you could never turn on because then it like blasts out the camera. But I'm like, "There's some Edison bulbs, you know that this is not a sauna."

Joel Clermont (15:28):
Yeah, should be pretty obvious. I was just thinking my background, over my shoulder I have this giant Nintendo arcade cabinet and I was on a big Zoom meeting, you know 100 plus people. And I thought that'd be kind of distracting so I put it like a sheet over it and that was more distracting because everybody was texting me like, "What's under the sheet?" So trying to make it less distracting actually made it more distracting.

Aaron Saray (16:01):
Do you listen to these podcasts and think, "Boy, I wish Aaron and Joel were on my team to help."?

Joel Clermont (16:06):
Well that might actually be a possibility. Head over to nocompromises.io, right on the homepage you can see what we do and book a call with us if you'd like to learn more.