Subscribe
Share
Share
Embed
Creators & Guests
What is No Compromises?
Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.
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:07):
And this is Aaron.
Joel Clermont (00:21):
Each year at Laracon a new version of Laravel is announced and developers get all excited about the new features and how great they will be in their day-to-day work. But the reality is that, in order to use those new features, you have to upgrade your application, or for many of us, applications, plural, to that new version which is not without its potential challenges. As long as I have been programming for money at least, on the web, some qualifications there, this is a challenge. It's not unique to Laravel, it's not unique to PHP. There's always-
Aaron Saray (01:06):
You get paid to program?
Joel Clermont (01:10):
Yes. Don't you, Aaron?
Aaron Saray (01:13):
I've been doing something wrong.
Joel Clermont (01:14):
Doing it for fun? But the fact is there's this tension between just using what you have, sticking with it, adding features, maybe adding value, if you're working on a business product. And maintenance tasks, like patching dependencies or bigger tasks, like upgrading the version of the main framework that you're using. And I have my thoughts on this, but I don't want to ramble too much. I'll kind of hand it off to you. What is your approach to thinking about that balance?
Aaron Saray (01:50):
Well, I guess it's almost like, where does that tension come from? Does it come from the business not wanting to invest in time to upgrade and upkeep? Or does the tension come from developers finding that part as boring? We're not doing cool new stuff, we're just installing new software and making sure our existing stuff works. Either side of that, I guess, is a different type of challenge and has a different approach to it.
Joel Clermont (02:19):
Well, let's take the developer side of it, right? I'm a developer, I might be a little weird in that I actually kind of like maintenance tasks sometimes. I mean, there's a certain aspect of it that's a little zen and you're making things better and you... Well, it also appeals to a little bit of the fiddly nature of things that I like to do sometimes. Where you're sort of putting off a bigger, more important task by doing something else that you can justify. Like, "Oh, this is important," but it's not really, necessarily your top priority.
Aaron Saray (02:52):
Procrastination.
Joel Clermont (02:53):
Procrastination, yeah. I've heard that word once or twice. But personally, if it's my own project, where I am the decision maker, nobody's paying me to do this and I don't have any other business people to report to, I would probably be a little bit more aggressive with upgrading. But like you said, "When there is a business involved that's paying the bills and maybe some other decision maker, then it gets a little more tricky." Like, how do you frame the upgrade work in a way that they'll get why you're doing it? Or, do you just say, "You know what? This is a necessary thing, I'm just going to do it. It's not got to take that long." We're not talking about maybe weeks to upgrade a project. Ideally, it could be hours, or a day or less. But that's a challenge that I've had to face a lot. Because for the most part, I'm working on other people's projects, not on my own.
Aaron Saray (03:48):
It's like when you take your car in to get some service and you ask them to do a thing and then they go and they top up your fluids. You don't necessarily ask them to do that, but they know that needs to be done. But on the flip side, sometimes when they're topping up your fluids or checking your brakes, they come back to you and say, "I think you need to have brakes replaced." You're like, "Ah, why were you doing that thing for me that I didn't ask and now I have another problem?" They didn't create the problem, they just found it. That's the conversation you have to have with the business too. Is, while you go and upgrade software, which is very important, that sometimes you'll find things that you didn't necessarily know were got to be a problem. It's just the nature of when things change.
Now, I think that brings up a good point is there's a lot of battles that I've seen in the past. Like, programmers want to upgrade the software, but somehow the business tells them, "No, we need to work on new features." I think that isn't exactly what happened. In the end it was the communication of the importance of those upgrades wasn't shared properly. Sometimes there's risks, sometimes the business has to take on the risk. But you really have to kind of explain that, "Just like changing oil, we need to upgrade our software as well. Otherwise, the engine will blow apart."
Joel Clermont (05:07):
Well, and to add to that the longer you go without doing it, the worse it gets. At some point you're got to have to do it or you're going to just throw the application away. Like, you'd throw your car away instead of fixing it. But the longer you wait, the harder it's going to be to eventually do it. I guess, this might be a good time to talk about maybe part of the solution is making it so it's not so hard to upgrade. For me, the thing I focus on is tests. Like, if you have decent test coverage and you have, not just like a metric, but you have actual confidence that your tests are valuable and catching everything, all the important pieces of your application, then just try and upgrade, see how many tests break. And maybe it's only one or two, well then, yeah, just go ahead and do it.
But if it's like 50, then maybe you have to schedule it and make more of a case to the team or the business owner, or whoever needs to make that decision. Well, for me, where I land on this and I guess the principle I use to guide the decision is, I see upgrading as important all the way from the framework itself to dependencies. And it's important enough to me that I do the things, like testing, communication with the business people, like budgeting time for it to make sure it gets done. But I'm also not eager to be on the bleeding edge. I don't like to install the 0.0 release, maybe not even like the .0.123 release.
Aaron Saray (06:43):
Yeah. I mean, it can be exciting to install a brand new thing but I guess it really just depends on the risk tolerance of the business you're working with too. So if you're working on maybe an MVP for a business and that code is going to be likely thrown away. And they're okay with some bugs because they're moving fast and there's a new feature that you need for this last week and all these things kind of line up? Maybe there's a reason to do that. But in the vast majority of this stuff, we sometimes confuse our own desire to be on the bleeding edge and keep current with the business's desire to have a strong, predictably boring but successful product. And in the end, bugs erode trust with the users. And if you erode enough trust of users, those users go away, they stop paying the bills and you stop getting a paycheck. And I hear some people get paid for programming.
Joel Clermont (07:42):
That's true. Yeah, I've heard that too. My takeaway from what you just said, Aaron, is that boring is sometimes good.
The last two weeks I've had the occasion to go to the eye doctor. I don't dislike the eye doctor, but what I dislike is having things put in or even near my eyeballs. Before I ask the question I want to ask, Aaron. Let me just ask you this, how do you feel about eye drops or people touching near your eyes?
Aaron Saray (08:28):
Oh, man. I wear glasses now, I wore contacts for many years. But they told me after the first couple months you should stop jerking your head like a horse whenever you tried to put them in. But no, after years and years, every day I'd go to put on my contacts and I would still just display my horsey mane through just... I don't know, it was bad.
Joel Clermont (08:52):
Okay. Well, what I'm hearing in your answer is that... you're going to [crosstalk 00:08:58] with me?
Aaron Saray (08:58):
My very articulate answer?
Joel Clermont (08:59):
Yes. But even though you... My issue is, I'm horrible at this. Even eye drops, they pretty much have to get a head restraint to put a drop in my eye. I feel like you're further along the curve than I am though if you actually regularly put something on the surface of your eyeball. So here's my question for you. I'm a grown man with children, but I'm kind of a baby when it comes to eye drops, is there a technique that you can guide me so that I don't have to look like such a fool when I go to the eye doctor?
Aaron Saray (09:36):
I think we've clarified that, I also look the fool pretty much all the time.
Joel Clermont (09:42):
All right.
Aaron Saray (09:42):
No. I like to tell my eye doctor each time, just, "Remember I'm that weirdo." That even when they do that puff into your eye to check for glaucoma, I pretty much jump off the seat. So I don't really know if I have any tips, but I tell him that. And a couple times he's really gotten me. He counted from three, but dropped them two. He is like, "One, two. Drop." I'm like, "Ah." But still even my eye, it's just like, "I see it coming." I'm like I can't do anything good at sports, but somehow my eye to eye drop coordination, super-fast.
Joel Clermont (10:22):
Oh man. One of my favorite events at the eye doctor was taking one of my teenage children there, and they had never had the eye puff test done before. He was sitting in a rolling chair and he literally rolled about 10 feet away when the puff of air hit his eye. To this day, that is a happy place I go to just thinking about the reaction of everybody. It was pretty great. All right, well, I feel like I have, maybe, some strategies to work with, so I will see how it goes next time.
Aaron Saray (10:57):
You need help developing a plan to upgrade to your application?
Joel Clermont (11:00):
We can help. Schedule a free consultation on our website nocompromises.io.