Joel Clermont (00:01):
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):
This is probably going to be the last episode in the series we've done on how we work on projects. Maybe we'll think of something down the road, but we're basically talking about wrapping up the project. How do you know when you're done, what happens when you're done, those sorts of things. It kind of seems like a logical ending point for what we've been talking through. But it's a surprisingly complex question because a lot of times you would assume, "Well, I'm done when I'm done with the project. Like, what's the question?" But it's more nuanced than that. So let's talk through it. Aaron, what do you say?

Aaron Saray (00:51):
Sure, yeah. I guess, yeah, that's the first question is, what does done mean?

Joel Clermont (00:55):
Yeah. Well, and it probably goes back to the very beginning, which is you have to specify what the goal of the project is. You might say, well, the goal of the project is to build the app or to launch the site or something. But it's got to be more concrete than that because otherwise you can always think of things to do, right? You could always write more tests or you could polish up that rounded corner on a button. I mean, it's an endless stream of potential work to do so you have to, ideally in the project proposal, define what are we building? How will we know when it's done? And what is the scope of this project? So you can actually look at it and be like, "Yes, we actually are done."

Aaron Saray (01:35):
Yeah, you made it sound like on average it's the developer who wants to keep it going. It's usually the client that's like, "I have more features," and, "What about this?" And, "We forgot about that."

Joel Clermont (01:43):
Oh, yeah.

Aaron Saray (01:44):
I don't think most projects go on longer because the developers are like, "I know you wanted me done, but I need to spend a little bit more time writing more unit tests." I mean, ideally we would but I think it's probably more like, "Oh, we just covered this," or, "is this a bug?" or whatever. Or a feature that's not defined and whatnot.

Joel Clermont (02:02):
Yeah, that's a good point. It's usually not us dragging it out, that's for sure. Let's assume we have that spec and the spec, the proposal where you define what the scope is, should also define what the timeline is. So it's not just purely a deliverable, but it's a deliverable and a timeline that go hand in hand. That kind of takes off the table a client or anybody really kind of trying to drag it out because there's all these other things that could be done. It's like, "Well, no, this is the deliverable and this was the timeframe we gave." So when we hit that timeframe if you still want to continue testing it before we launch it, that's fine. But we're done in the sense that the project is complete." Especially if that's tied to a final payment or something.

Aaron Saray (02:49):
Yeah. I still think that's complicated though because when you think about it, they could pay you so you consider you're done, but then they're still testing and they're still finding more. The little bit of special sauce that I don't know if you're going to mention or not is, it has a lot to do with the entire project timelines communication. As you go through the project... I know we don't like to have meetings, we'd rather just put your head down and develop or whatnot. But you need to stay connected with your client and give them understandings of this stuff. The idea is actually most of the programmers they're good people, we're good people.
We're nice, friendly, smart, so when someone gets to know us and understands that we want the best for the project too you have this conversation. So at the end it isn't you just suddenly saying, "Yeah, I disappeared for three months now here it is, and bye." They had known that over this time, I was like, "Well, we're getting towards the end. We're getting towards the end and we're going to have a conversation." Then it's like, "Okay. Now, remember how we talked about this is the end of the project? You know, if we find anything more, it's going to be a new sort of declaration."

Joel Clermont (03:54):
Yeah. And maybe that's kind of a good time to transition the conversation into that post-launch or post-project support. Because we don't want to give the impression like, "Okay, we're done." We cut and run, we'll never talk to you again. The reality is once something goes live, there's a period of time where the bugs are shaking out of it, right? Speaking for myself, nothing I've ever launched has been 100% perfect and has not required at least a few bug fixes. It's just the reality. We build in to that same timeline, a period of post-launch support, and it's going to kind of depend on the size of the project, right? Like, if you're working on a project for a year, you're not going to be like, "Well, we'll support it for a week and then we're done," right? If it's a longer project, it generally will have a corresponding longer support period. But in our case... I mean, I'm just thinking back on some projects, like usually a month or two is kind of power for the course. Like, that's enough time for it to be live for enough real users to interact with it that anything serious of course would be found. And usually, even a lot of little things will be found in that timeframe as well.

Aaron Saray (05:06):
We'll put that in our proposal too, saying, "Here's our timeframe of testing. And if you want more after that we're not going anywhere but it's going to be a new project." The other thing is, this happens in a lot of other industries and its fine. You might hear some horror stories but they set expectations properly so that's something we can learn. Builders who build your house, you have a move-in date where you then go into the house or whatever and maybe they'll fix a few things afterwards but they're not going to call them three, five months later and be like, "Oh, well this whatever is broken now." They're like, "You got the house, you accepted it." Same thing with cars too. You buy it and then maybe the first week or something, they're like, "Oh, well, the air conditioner broke." They're like, "Okay, fine." But after the first week or two they're like, "Well, I mean, you bought the car."

Joel Clermont (05:57):
Yeah. So you can't be like, "You know, I just don't like this color wall. Could we redo that? I know it's been six months since we moved in." "No." That's good, a concrete example like that is useful for framing this. Now you mentioned if something else comes up, "Well, that's another project." So one of the things that's kind of a gray area, if you will, or maybe something that a client certainly would think about if they're not technical is maintenance. I mean, for example we're building apps in Laravel. Laravel has roughly an annual release cycle for major versions and in between there's all sorts of other things that may be important, like security fixes or versions of PHP as well. That's something that is important to communicate as well and we don't do things like that, I mean, unless it's a critical security issue. Like, we normally wouldn't include upgrading Laravel as part of the post-release support period. That would generally either be a separate maintenance contract or just something we'd bundle in with the future project.

Aaron Saray (07:02):
I think there's also a point that we try to educate our clients in saying that, you know, there's maintenance. There's maintenance to software, like there's maintenance to everything else and just like everything else. I go with cars a lot. You know, you can pay to have your oil changed and like, "I don't want to pay that a hundred bucks for that oil change, or whatever." And you're like, "That's way too much," right?

Joel Clermont (07:20):
Right.

Aaron Saray (07:20):
But if you don't change your oil, it's many, many thousands to replace an engine. So that's kind of how I tried to explain it. I was like, "Hey, everything has maintenance. Your house has maintenance, car does, your garden..."

Joel Clermont (07:34):
My garden?

Aaron Saray (07:35):
You got to weed your garden.

Joel Clermont (07:36):
Okay. All right, I see where you're going. It also kind of depends on the team we're working with. So if it's a non-technical founder or something and we are the only developers, that's a little different than if we're working with a company that maybe has a team of developers and some of this maintenance stuff might just fall on them. Like, we don't need to do it, it's not really complicated work. Especially if you have a good test suite and things are documented well, like upgrading to the next major version shouldn't be a multi-month project. It should be relatively straightforward. But so those are the things... But like you said, communication is key. So it's not a surprise conversation three months post-launch. Like, "Hey, you know, we need to do another huge project to update this." No, we educate them much earlier in the process so they can decide how to handle that.
There's some weird things I catch myself doing and I hope you can relate somewhat, Aaron, then I don't feel quite as weird. But I'll give you a couple of examples. I get these weird patterns of thought. For example, this was a while ago, but I noticed I'd be in the shower and I'd always be singing It's Not Easy Being Green by Kermit the Frog. And I'm like-

Aaron Saray (08:59):
What?

Joel Clermont (08:59):
... "Why do I always sing the song in the shower?" And I had a moment of self-reflection. Because it's not like I walk around the house all day singing that song but I caught myself doing it like several days in a row. And then I realized when I go to my dresser to get clothes to take into the shower, on top of the dresser, at the back, there was a book with a picture of Kermit the Frog on it. And somehow that got into my mind and the natural occurrence, the natural pattern of thought, was I would be singing, It's Not Easy Being Green.

Aaron Saray (09:33):
I mean, there's a lot of questions I have but one of them would be like, why do you have a book in your bedroom, you adult, with Kermit the Frog on it?

Joel Clermont (09:42):
I could say, "I have kids and that's why," but that's actually not the reason. But it was more of a philosophical Muppet's book that was like inspirational quotes and stuff. This was a long time ago, I don't even know where the book is. But that's the real answer.

Aaron Saray (09:59):
I thought you were going to say something like, how I find now that whenever I sit down I creak and groan. I'll sit down and I'm like, "Argh." I don't know if that's just getting old or like... I didn't really notice when was that or I'll sit down and go, "Oh." I didn't really notice until I had a visitor the other day and after the third time she's like, "What are you doing? Why are you making so many sounds?" And I'm like, "I'm making sounds? Oh no."

Joel Clermont (10:30):
Yeah, that's along those lines. Let me give you one more weird example.

Aaron Saray (10:33):
Yeah.

Joel Clermont (10:34):
Okay. When I make coffee in the morning, I open the cabinet and inside there's a bunch of things in this cabinet, but one of them is a box of salt and it's Morton brand salt. And you see at the top or sometimes the bottom of boxes, they'll have like a lock code, whatever. Like, numbers and letters to identify it in case there's a dead mouse in it or something and you have to call and complain. So this one had at the top of it VG148 or something. For some reason, every time I open that cabinet and I see that box of salt, I think about the actor from Lord of the Rings and I say, "Viggo Mortensen." It's not like I prepare to open the cabinet and I'm like, "I'm going to say that," but I just see it and that's where my brain goes and I'm like, "Oh man. Joel, come on."

Aaron Saray (11:35):
How do you know your Laravel site isn't being hacked?

Joel Clermont (11:37):
Well, security is one of the things we talk about on masteringlaravel.io. There's a free e-book you can download with practical tips to secure your Laravel app.