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. One of the things that I've got the joy of being tasked with multiple times in my career was building a proof of concept. And that's great because you get to kind of work on something that you're like, "I think this is going to work, but I'm not sure how." I really can't quote level of effort if I don't even know how it's going to work. I can run this through real quick and put together some technologies. I know that we've done it together on multiple projects we've worked on too, when there's like, "Hey, could you make some middleware to connect these two larger enterprise systems?" And you're like, "Probably."

Joel Clermont (00:50):
"Maybe."

Aaron Saray (00:51):
"So let me do a proof of concept." So I've put a lot of those together. And one of the things that really chaffs me though-

Joel Clermont (01:01):
Wait a second. You just said joy. First of all, is your joy sincere or is it sarcastic joy?

Aaron Saray (01:06):
No, it's joyful up until it's done.

Joel Clermont (01:09):
Okay, got it. Okay, continue.

Aaron Saray (01:11):
This has happened to me multiple times, I'm sure it's probably happened to the listeners too. Where you show the proof of concept to the stakeholders and they're like, "Cool. Let's put it in production". You're like-

Joel Clermont (01:22):
Oh boy.

Aaron Saray (01:22):
"No, no, no. This is very junky code, it just barely works." And what they hear is, "Well, it's done. You show me how it works."

Joel Clermont (01:32):
"It works. You said barely works, but it works."

Aaron Saray (01:34):
"Yeah, it works. We're not going to waste time. You already did the work, we're not going to waste time to do it again, and so we're just going to put it out there." I think it's really hard, unless you've developed a good relationship with your business to explain to them that just because something works doesn't mean it's going to work long-term. It'll actually cause more headaches, it'll cost more money to work on, it might go down in and erode customer trust. You really have to kind of work through those conversations with your stakeholders for them to understand that you're not just trying to waste time and build it again, right?

Joel Clermont (02:05):
Sure, right. So just to kind of make sure we're on the same page. When we're talking proof of concept it is functioning code so it is something that you could... it's not like wire frames or mockups, but it is something you could theoretically ship to production which I guess is a problem we're talking about. But it's done purely as an exploration to figure out maybe there's three different ways of doing this which is the right one. From the developer perspective you're saying, "This is never intended to go live, it's meant to be thrown away." But from the stakeholder perspective, they see it and they're like, "Let's go live with that." So that disconnect is what we're trying to solve here.

Aaron Saray (02:45):
And when you say, "It's just kind of real quick code," maybe there's no error handling?

Joel Clermont (02:49):
Sure.

Aaron Saray (02:49):
Or it's just set up to run in a perfect scenario and because you're in... A lot of times proof of concepts are in very small environments too. So if we take 1% of our traffic and run it through this proof of concept, did it work? Yes. But that doesn't mean it's going to handle 100% of the traffic all the time without errors. Maybe there's no unit tests or anything like that, so you got it to work once and you're like, "Now, if no one touches this ever and we don't put any traffic through it, it works like I've just shown you."

Joel Clermont (03:17):
"With this carefully constructed demo, I can show it working."

Aaron Saray (03:20):
"Yeah, this is great." So you want to make our base out of just binding wire and bubblegum, awesome. The issue then becomes, "So what do I do then when I'm building proof of concepts if I'm afraid that that sort of thing might happen?" Because there's a lot of people that like to talk and we've talked sometimes too, like, "Well, you just tell them no." Well, depends on where you are personally in your career, what political capital you have. Do you have savings account that you cannot have a job if they freak out?

Joel Clermont (03:51):
Right.

Aaron Saray (03:51):
There's all these different things to weigh. So sometimes the answer isn't, "You tell them no and we do it the right way," sometimes you just can't do that. And I hate when people give that advice, "Just do it the right way." It�s like, "Well, yeah, okay. That's-

Joel Clermont (04:02):
Well, and even if that's the ultimatum you get to, if there's a way to prevent getting to that point I think that's the smartest strategy anyways.

Aaron Saray (04:11):
And that's why people think you're so friendly versus me that, ah. So what are some of the techniques that we'll do? And this actually is funny because this idea was inspired off of a proof of concept me and you did together. And I saw the code and I was just... you might not know this, I was very, very angry because it was such a... Basically, we were doing some proof of concept with some stripe stuff.

Joel Clermont (04:39):
Oh, I know what you're talking about.

Aaron Saray (04:39):
And it wasn't even in controllers, it was like all in their routes file. I'm like, "Oh, I can't even..." My idea was at least I would copy some of this and put into the real app or whatever. And they're just passing things around out of the request directly and I'm like, "What are you doing?"

Joel Clermont (04:57):
See what I did? I headed you off from using my proof of concept in any way, shape or form.

Aaron Saray (05:02):
So number one, do it so bad that other team members can't copy it.

Joel Clermont (05:06):
Exactly.

Aaron Saray (05:07):
But I thought we would talk today a little bit about like what are some of the things that you can kind of do along the way when you know this might be a danger? We don't want to invest too much time in making a great, huge, level of application development that we would in our normal app. But there are some tips along the way that we can do on our proof of concepts that will get us to at least a better point if we are kind of forced to throw those into the mix, into production.

Joel Clermont (05:34):
I'm excited to hear your wisdom, Aaron.

Aaron Saray (05:36):
Oh, I thought you were going to add them.

Joel Clermont (05:38):
Oh, you're setting this up? Okay. Now, Joel, tell us how to do that. Well, I gave you my tip. My tip is just to make the code so unpalatable that they would never be considered.

Aaron Saray (05:48):
The first thing I do is... So I'm going to go on some more specifics. Imagine that you're doing a proof of concept between your core platform and a payment vendor, and you know that there might be more than one payment vendor in the future and those things might change and all that kind of stuff. You could just write for your one payment method one vendor and put it all in the block of code and call it good. But if you've been doing programming for a while and you know about PHP design patterns, things like that, you might go and say, "I want to make a strategy class," and then that way I can put in different versions of different strategies for different payment vendors. Well, doing that whole thing right now is way overkill because you don't even know if this is going to work but there's that middle ground. You go and you see this idea of... Like, you see you have your main code block and then you can take all the stuff that's specific to your vendor and just put it in a private or protected method instead.
So your main workflow then calls this method which does, again, just hard coded workflow, your round runner let's just say is stripe and returns an object or a set of values that the rest of the main workflow can work with. The idea there is that it's kind of good progress in a way, you've kind of broken up the code but the idea would be then if you get to a point where you want to start refactoring things to add more, now you only have this one small little method which you can take all that code and extract it into a strategy and then build on different ones. So the main workflow that we know is kind of working now, it's still going to call that protected or private method, and then that's just going to use different strategy classes to return the sets of values. And you start to encapsulate that information into smaller segments and right away it should be digging in your head like, "Well, if we have those all in little strategy classes, that means that you're getting set up to run in unit tests and all that kind of stuff too." Yeah, exactly. That's probably the first thing I'd do is when you're running through this stuff and kind of thinking about this, think about where are the places that I might maybe encapsulate or change into something more complex if this was the highest quality of app? And go a middle route on planning that. Like, we don't want to go too far because you're not going to need that, right?

Joel Clermont (08:03):
Mm-hmm (affirmative).

Aaron Saray (08:03):
But you just don't want to just vomit all the code out in one straight line either.

Joel Clermont (08:09):
Just to make sure I'm tracking. Your strategies are less about trying to head off the business person from using this proof of concept and more just mitigating the fact that when they inevitably want to do it, it's not going to be as horrible. Because you've kind of built in some points of extension or you haven't painted yourself completely in a corner for something meant to be thrown away. You're making it where it, like you said, that middle ground where, "Okay, now we have to make this real, here are the 10 places that I can logically start by making this more of a production app." Is that correct?

Aaron Saray (08:44):
Yeah.

Joel Clermont (08:44):
Okay, cool.

Aaron Saray (08:44):
You're right. Because I personally think it's really difficult, especially when you're in your earlier part of your career, to find footing to say no.

Joel Clermont (08:55):
Yeah, so it's preparing for the inevitable but not preparing so much that you're actually slowing down the proof of concept significantly.

Aaron Saray (09:02):
Right.

Joel Clermont (09:02):
Okay. I like that. Good tip.

Aaron Saray (09:03):
A second thing that we can do along this proof of concept path is, it doesn't really take that much time and we've actually talked about this before, is you can set up your unit test stuff and just write the names of the methods that indicate what you would test if you were and just mark them as incomplete or to-do or whatever. Because, again, when you come back and look at this there's a whole bunch of stuff you're going to have to spin up in your head to understand like, how does this work again? Because that's also been my experience between new proof concept, its like, "Oh, that's awesome. Let's put it in production." You're like, "If you put it in production then you get taken away onto something else." And something happens on this broken piece of code that never should have been there, three months later and you're like, "How does this work again?" Because it's doesn't even look something I would write because I didn't write it to be kept.

Joel Clermont (09:51):
Just maybe this is a tangent, but would... For sure I'd get the incomplete or to-do tests, would you ever leave comments in the code? Would the comment be those extension points you're talking about? Or would you go beyond that and be like, "All right, if this ever makes it to production, do this, this, and this."?

Aaron Saray (10:08):
I mean, I'd like to say that those matter but they don't.

Joel Clermont (10:13):
You'll ignore it later?

Aaron Saray (10:15):
Yeah. Though in my experience the only good sort of comments, and I love comments, but are to explain a workflow that isn't incredibly clear. A lot of times when you're working on a good quality piece of code you work on your unit test and you refine this code until it looks so simple and elegant that you're like, "Wow, this looks like it was easy to write." When you know that it took a lot of time to make it look like it was easy. During that process you can write kind of comments and explain things that aren't so clear yet or why did you do things. But I've many times wrote notes that said, "I'm going to do this later if we're going to do this." More often than not you're too precise or you're not right on what's actually going to happen in the future. And if you're continuing to be good at your craft, you probably know an even better way to do what you're saying needs to be done by the time you come back to this code.

Joel Clermont (11:07):
Yeah, that's a good point.

Aaron Saray (11:10):
I've written notes in a way in the past that said, "Oh, do this," when I come back I'm like, "Why would you ever do that? It's a bad idea."

Joel Clermont (11:17):
It's always been funny to inherit a code base from somebody else and you'll see to-do comments and then you looking to get history and that to-do is seven years old and you're like, "Yeah, that's never getting done." So fair point.

Aaron Saray (11:30):
And then the third and final sort of thing is kind of a sort of planning thing after this has made it to production. Because it's going to go there and we wished it didn't, we tried, it's gone there.

Joel Clermont (11:40):
We're just too good, it just makes it to production every time.

Aaron Saray (11:44):
Yeah. "Why doesn't the rest of your stuff go this fast though?" Is once it's there and you're going to be asked to add new features or fix things or whatever, you have to work in sort of your maintenance on this project then. We're not talking about totally rewriting things for things that aren't happening, but there are areas that you know, "Now that it's in production, this should be done differently." Put some error handling in there or whatnot. So every sort of thing that they ask you to do need to work in like 50% more time just to start to build this thing up for them. Because in a perfect world we like to say that, "Yeah, they should understand these risks and if it goes down, it's their business." But if you've been doing it for as long as we have you know that when it goes down it's their business but it's your fault.
So depending on what kind of contracts you have, you have to go and fix it maybe when you (inaudible 00:12:34) go on your time off or not, you don't want to tell them, well, you shouldn't have wrote such broken proof of concept work. But anyway is the idea, like I said, to plan in these additional things and it's just like, "Okay. Could you add on this one integration?" "Sure. That's going to take x amount of time, which involves doing that integration and adding error handling." And then the next thing is then adding logging and then writing out these unit tests. Sort of build on that. You just kind of have to claw back some of that stuff after it's been into production. And it's important for you as a professional to know that you just have to do that, that's part of your job.

Joel Clermont (13:12):
Yeah, I really all of those strategies, Aaron. Again, greenfield, perfect scenario, this would never happen. But hopefully these tips will save you some heartache down the road if you find yourself in this situation.

Aaron Saray (13:30):
So I got a problem with birds.

Joel Clermont (13:33):
Okay.

Aaron Saray (13:36):
I mean, I grew up on more of a farming area and we had chickens and I remember sometimes you'd have to throw stuff into the chicken coop or bring in various straw and mix of stuff to kind of give them a bedding. And there's a rooster in there and a bunch of hens. And every time I'd open that door to kind of put some stuff in there that rooster would be like, "Oh, it's hot." He'd just come at me making those rooster sounds. I'm not going to try to make a rooster sound right now because I know it's going to come out bad. It's like whenever I try to do an accent and you're like, "What was that?" I'm like, "I don't know."

Joel Clermont (14:12):
I can really get it.

Aaron Saray (14:13):
Mini stroke. It's clearly sewed into my mind this one time this stupid rooster was... Like jumps up on the wheelbarrows, I'm trying to dump it in there. I was like, "You want to fight?" Screaming his rooster sounds and I panicked. I was a teenager and I'm like, "If the rooster gets out, my mom's going to be so mad." So I did the only thing that you possibly can do when a rooster has jumped on your wheelbarrow threatening you, is punch it right in the face.

Joel Clermont (14:42):
This rooster? (00:14:45) faces?

Aaron Saray (14:45):
Yeah, apparently I was a good aim when I was younger.

Joel Clermont (14:49):
Nice.

Aaron Saray (14:49):
I've none of those athletic skills now. And just punched them in there. But it got me thinking about all the other weird bird run-ins that we end up having. I don't know if it's-

Joel Clermont (15:00):
You say we but don't drag me into this.

Aaron Saray (15:02):
Well, I think you have run-ins too. The other day I was walking in a park with my friend and there's a bunch of Canadian geese. They're protected so you can't mess with them, but there's just so many of them now especially around water in our area. We're walking and they're on the middle of pathway, I'm like, "I guess we now have to leave the pathway because of all the geese." So I'm just quietly walking around them and she looks at the goose and she's like, "Don't you give me attitude." I'm like, "Don't talk to the goose."

Joel Clermont (15:35):
Or make eye contact.

Aaron Saray (15:37):
Yeah. And the goose was like, "Ah," and started hissing her. And I'm like, "I've never seen a goose hiss." Like, "What are you doing?" She's like, "Stop it. Don't you hiss at me." I'm like, "Stop doing that. I don't want to be attacked by a goose". But she's like, "Oh, they've bit me in the back of the leg." I'm like, "Yeah, because you yell at them." But I was getting my punch ready.

Joel Clermont (15:55):
You came prepared. You're like, "I've dealt with this before." Aaron, can I just ask you a question with your deep farming experience?

Aaron Saray (16:02):
Oh-oh.

Joel Clermont (16:02):
I just remembered the other day I was googling something and you know how you start typing into auto complete and then it fills out the question?

Aaron Saray (16:11):
Yeah.

Joel Clermont (16:11):
I don't remember what my question was, but I typed something like are eggs and it auto completed are eggs dairy. And I'm like, "Why would you think eggs are dairy?�

Aaron Saray (16:21):
What?

Joel Clermont (16:21):
Maybe because they're both on a farm.

Aaron Saray (16:24):
No.

Joel Clermont (16:24):
But at least in my Google experience, that is the first auto complete when you type are eggs, are eggs dairy?

Aaron Saray (16:36):
So for over 75 years I've been writing a blog on my personal website, aaronsaray.com. So you can check that out for articles about programming, business. Or maybe the last 7, 10 years.

Joel Clermont (16:48):
I haven't been blogging for 75 years but I do have 75 years with PHP experience. And you can read about that at joelclermont.com.