No Compromises

Why is it important to think about a future project hand-off at the beginning of a client relationship? Aaron and Joel share their approach.

Sign up for our Laravel tips newsletter!

Creators & Guests

Host
Aaron Saray
Host
Joel Clermont

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:08):
And this is Aaron.

Joel Clermont (00:16):
Recently I was handing off a project and in this case, I wasn't handing it off to another developer. I was sort of handing it back to the client because it was going to go on mothballs for a while. But I wanted them to have everything they needed in case they wanted to resume the project and I was not available. Going through that exercise... now this is an older project going back five, six years now. My practices have improved since then, but I found some gaps in what I had already documented and it took me some effort to dig some of those things back up to put it back together. So I thought it might be an interesting topic for us to talk about today. Any tips or tricks on running a project with an eventual handoff in the future that is hard to predict when it might happen?

Aaron Saray (01:08):
I think that's a good topic. I would say that I want to just extend it a little bit or just change it a little bit and say not only handing it off but just coming back to it yourself later.

Joel Clermont (01:20):
Yes.

Aaron Saray (01:21):
Let's be honest, just coming back to it right away there's many times that I've done something and then, let's just say, I destroyed all my Docker containers in a fit of rage. Then I was like, "Wait, what did I do to get this running again?"

Joel Clermont (01:34):
Right, yeah. I think that's fair, that's in scope for this discussion. It ties in well with what I had in mind. I thought maybe even starting, as developers we focus a lot on the technical aspects, but there's stuff involved in a project that isn't really code or Docker configurations. There's, like, where do you host the site? How was that provisioned? Who owns that site? How do you grant access to the server? Or, how are you sending mail? Is that going through this service or that other service? Or any number of different things. Trying to recreate all those steps... I've been that guy inheriting the project where none of this was documented and that's a lot of trial and error. Having that all-in-one document is a huge win for the next person that picks it up. Whether that's me or some other dev in the future.

Aaron Saray (02:30):
Where would you put that kind of documentation?

Joel Clermont (02:32):
I've experimented. In this particular example, it's in a readme.md file in the root of the project that I'm handing off. But if it's an active project and it's on GitHub or a place that has built-in Wiki functionality that is a nice place to put it. Because then it's with the code, then you hand off one thing and it belongs in there. It lives in the same spot that the code lives in. The place it's a little tricky is sometimes there might be things you want to capture and document that are sensitive. Passwords, access to accounts, things like that, so that clearly wouldn't go in the wiki. I generally use a password manager locally and the biggest thing I do is I never hold the main credentials for something. If a customer is going to host a site on AWS, they set up the AWS account and invite me to it so I'm never left holding any sensitive credentials that are really for their account and their account only.

Aaron Saray (03:32):
Well, it sounds like you must have some pretty technologically advanced customers then, if they can set up their own AWS configuration and everything. Or, what do you mean?

Joel Clermont (03:42):
Not the configuration. I have a bunch of documents that I've captured over the years for how to set up an AWS account, how to set up a DigitalOcean account, how to invite me to your DNS provider, things like that. GitHub, those sorts of things, I've had pretty good success with relatively non-technical clients being able to create an account and follow my steps to click the buttons to invite me to their account with full privilege access, generally as an administrator, owner, or whatever that platform calls it. But the main thing is, I don't want to know their AWS password, especially when they use their personal Amazon account and it's tied to their full purchase history and Amazon Prime videos and all that sort of good stuff. So it's a nice level of installation. Then when I want to leave a project, I just remove myself and I don't have access to it anymore.

Aaron Saray (04:37):
That sounds actually pretty cool. Where would I get a copy of those so I don't have to write them myself?

Joel Clermont (04:44):
You know what? They're not published right now but by the time this goes live, I will put them up on the No Compromises website, so nocompromises.io. And at the bottom, in the footer, I'll have a resources link and I'll make those templates available because they'd be beneficial to other people too. That's a good point, I don't mind sharing.

Aaron Saray (05:02):
Nice.

Joel Clermont (05:03):
Giving back maybe a little to the more technical aspects of a project. What have you found useful in terms of things to capture and document when you are working on a project that will benefit the next guy, or you a week from now?

Aaron Saray (05:17):
Right. Well, I got two things that I kind of do almost religiously. The first is, I rarely go and use a new service even if there's a better one, unless there's a huge huge benefit to that. I've been using SendGrid for my email because I use SendGrid from my email. Not because Mailgun isn't better or Postmark or any of those things. They might have better things but I use SendGrid because I have now invested some time in learning how that works. If I want to document it, it's easier and I understand how it works and I don't have to remember if I forgot to document it. Where is the email for that project? It's probably SendGrid because I use SendGrid.
I know as programmers we like to go and try the newest in technology and all that kind of stuff, but you kind of have to hold that back. Especially when you're working for a client, is don't always run towards the newest shiny thing, Not only because of stability and all those different things, but about the ability to have it repeatable and you remember it and all those different... there's other reasons there as well.

Joel Clermont (06:23):
Yeah. I think having standards is good, you know because you're not picking things fresh each time and making that decision when it doesn't... it's not really a critical decision. They're all pretty equally good.

Aaron Saray (06:34):
Yeah. The second thing I do which is, I would say it's always been worth it, it's always been worthwhile, I've always been so thankful but I never enjoy doing it, is I open up the README file or whatever and I write after each line I've done something, what I did. If I'm provisioning something for the first time and it's not going to be in some automated provisioning system or whatever, I will literally click on a link or something and then I'll write, "Click on this link," or something like that in my instructions. And it makes it so slow and it's so irritating but it�s worth its weight in gold when you come back to it and you're like, "Wait, how do you add another authentication method in Firebase? Oh, let me look at my first list of how I did it." You click that, you click that, you click that. I mean, especially with something like Firebase it's going to be like 80% accurate. They've changed it probably by the last time you've gotten in there. But it's the one thing that I learned to do. That I'll be completely honest, it's irritating but it's so worth it.

Joel Clermont (07:41):
Yeah, I can relate to that. In fact, with this handoff documentation I wrote I took it to another computer. I have my main desktop I work on but I also have a laptop I use occasionally. And I started from a fresh slate there and made sure I could get access to everything I told them they could get access to. Like, I generated a key pair and I said, "Well, you should be able to get in with this." But I tested it on a fresh machine and be like, "Yes, it actually does work." So validating that README hopefully will save me some grief in the future when somebody actually tries to use it.

Aaron Saray (08:16):
There was another thought I had about your idea that you create everyone... or you have everyone else create their own account. There's a lot of times when it's like the idea that maybe if I was a reseller and I provided service for them I can get this recurring revenue. But you really have to measure out, is your business model as a programmer or a contractor providing that service as a reseller? If it is, well then you have to have a lot of them to make it worth your time. Because editing one time people are going to be contacting you for assistance or whatever. If it's not and you just think, "Well, this is going to just give me an extra $10 a month or whatever." I can guarantee you it's never going to be worth it because all they have to do is contact you once in the next 6, 8, 10 months and now you're equal to an hour's worth of your time would have been that you could have billed out.
Or even worse, if they contact you once every four months for just one thing, now you're behind really when you think about billable time or anything like that. I would say that's another thing is not only do I have people make their own accounts for the reasons we're talking about, but also it's just never worth holding on to their accounts for them.

Joel Clermont (09:29):
Yeah, totally agreed, I've learned that lesson the hard way in fact. But now I do as much as possible to not be the only means of support for something like that. Especially a low volume, smaller client, there's not going to be a ton of markup like you said so it's not even worth it. On the sales side of things, I've actually called attention to the fact that, I kind of jokingly say this, but I make it as easy as possible to fire me in the future. Because sometimes clients have gone through that process where they really feel held hostage by their previous developer. They're unhappy and they want to sever the relationship but they don't know if they have all of the assets they need, they don't know if they hold all the accounts.
And it's a whole ordeal to try to get that stuff out of someone's hands when there's already a strained relationship. I've had more than one client actually say they liked that approach, even though at the beginning of the relationship, "Oh no, this guy's great. I'm never going to want to fire him." The fact is they might, things change-

Aaron Saray (10:32):
Then they get to know you.

Joel Clermont (10:33):
Then they get to know me. And on the flip side, it's not just about firing. What if I got sick or I decided I didn't want to do this anymore, or some other opportunity came along that gobbled up all my time. There's a lot of reasons to not be the sole person that can manage something for a client.

Aaron Saray (10:57):
One of the things I think is a little weird is the object of golf is to play the least amount of golf. Is that kind of weird? There's a thing where it's like, "Yes, if you do less of me you've done better."

Joel Clermont (11:14):
Having played golf, I can say that I will sometimes console my bad playing by saying I'm getting more of my money's worth. But, yes, that is an odd thing about the sport for sure.

Aaron Saray (11:25):
The longer I stay on the golf course, the more I'm getting my money's worth?

Joel Clermont (11:30):
Yeah, exactly.

Aaron Saray (11:31):
I actually know that. I worked as a groundskeeper at a golf course as one of my first jobs. I can tell you man, there is some weird experiences I've had there. I was a young man so I was really kind of... I thought I was smart and I was a little bit of a jerk. But one of the things we had was an issue where people would be playing on the... they were on the green and someone hits a ball and it lands near them. That happened one time. There was a dad and his kid were playing and then some guy hit something really close. And I was waiting there with the greens mower with the really soft wheels. I was just so irritated so I jumped off the greens mower, I grabbed his ball, picked it up which you know is a no-no.

Joel Clermont (12:20):
Oh yeah.

Aaron Saray (12:20):
I drove back to him and I don't think he knew what was going on until I got closer to him and I hand him a ball. I said, "You don't hit while there's people on the green." Then I turned around real fast and I'm going to go back to the green, I'm driving as fast as I can. I hear the ball, he hits it, and then he starts walking-

Joel Clermont (12:39):
Oh boy.

Aaron Saray (12:39):
... he starts walking. And mind you greens cutters are made specifically to be really nice to the grass, therefore they also go very slowly. So he hit it and then he walked past me as I was angrily driving back to the green. He was like, "Okay, just that guy." And I'm like, "Man, this is the worst thing." But I got hit by a ball once because... and we had older equipment so it couldn't necessarily... It didn't have those seats, those special seats that would tell you if you could fall off or get knocked off or get off. I got hit on the side of a head when I was doing the mowing for the rough. I got hit on the side of the head and knocked me off the tractor. When you do the rough mowing, it has those pole behind ones that are like old school mowers. I got knocked off and I'm lying there, and then it just keeps going. Then two of those things run over my legs and cut them all up and I'm laying going, "Oh." Then I realize I now have to get up and run after the tractor to stop it.

Joel Clermont (13:40):
Oh boy.

Aaron Saray (13:41):
With all my legs bleeding and everything just because someone hit me on the side of the head with a golf ball.

Joel Clermont (13:44):
That's a double whammy. That's what you call that.

Aaron Saray (13:48):
But, yeah, it's funny too because people would pretend like we didn't know what was going on so many times. They come back with a golf cart and be like, "Oh, I don't know why, it's suddenly not working anymore." You have to smile at them and say, "Oh, just take another one. Ha-ha-ha." Then you go and you take it back and you put it up on a jack, and there's a full willow tree wrapped around the axle. You're like, "I know what happened. You went through the marsh and you got stuck. Then you're like, 'I don't know what ha...'" Just say what it was, we're going to give you another one but don't surprise me with the whole willow tree.

Joel Clermont (14:25):
By any chance did this golf course establishment serve alcohol to the patrons as they were playing the sport?

Aaron Saray (14:32):
Oh, yes. It did. There was a...

Joel Clermont (14:36):
Okay. That certainly is an impact on how well they played and the sorts of damage that probably happened.

Aaron Saray (14:41):
Actually, I think I don't really like golf anymore and I'm not entirely certain if all of these experiences have anything to do with it or not.

Joel Clermont (14:48):
I imagine they do.

Aaron Saray (14:53):
Would you like to get regular Laravel tips in your inbox?

Joel Clermont (14:56):
Sign up for our free weekly newsletter at our website nocompromises.io/tips.