Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron. It's difficult sometimes to determine what order of functionality and features to do when you're programming.

There's some obvious orders, like maybe I want to build a login screen so my users can log in and then change their password.

A lot of that stuff Laravel will give us, so we know that we can get our scaffolding of our project going.

But then there's how do we get

into various different sections of our application?

Maybe there's features for business users, there's features for professional users, there's features for standard users.

Each one of those has their own set of permissions, and functionality, user experience.

I think I ran into this recently, and I don't know if you agreed with my solution.

But I powered forward, and I'd like to know what you think about it after the fact.

We were working on a client project and in order to work on the functionality we were working on, it was very deep, very nested, far into there.

It was probably the most important part of their functionality, so it's a thing that they're concerned about.

So we were going to aim at that and start to work on that first.

By solving that problem we get the answers to a lot of other problems.

We're working on this very nested sort of functionality, which is multiple different layers of permissions and levels of users deep.

And I'm working through that and I've started noticing that, okay, it has all these different users and all this kind of stuff.

I need to start switching between different types of users.

I want log in with this type of user, I want to log in with this type of company.

I want to have all these different permissions set up.

And to get started first we kind of built out a seeder for our dev data and seeded in some of that data that we thought we might need.

But as I started building out more and more functionality, I started realizing I don't have all the users that I need.

I don't have all the different functionality on this.

Like, this user has a Boolean flake for something, and it's on, and I want it off for a test.

My question myself was, "Okay, I don't have the interfaces for all this other user editing stuff, and it's not what the client wants right now.

They want me to focus on this thing. How do I adjust my user?

How do I get them to a different state so I can test them in a different state?" My first thought was perhaps I should go and add more users to my seeder.

You could, yeah. Just explode the seeder with all the variations.

Exactly. And that's fine, except for now I have 12 different users, and some of those users I'll probably never use again.

And now they're in my database and all that kind of stuff.

I didn't really know what to do and I definitely suggest not doing this to everyone.

It's one of those, "Do what I say, not as I do." But I kind of went on a whim and did a very bare bones version of a different piece of functionality, which was the ability to edit my user's settings.

Only the few settings I would need for this functionality I'm building out the core functionality.

The user interface and editing that had many, many different settings.

And the task wasn't to build out the user interface in their settings, but I did go there and create a little bit of that functionality so I could be logged in and change my settings.

And what do you think about doing that? Making that sort of decision?

Not putting in more users in the seeder but kind of ignoring the sort of process that we have and building out another tool, another UI, only half done, to help me instead?

I tried to summarize the thoughts because I went through a process in my thoughts.

Because at first my reaction was, "Aaron, why are you doing that?

That's not the thing we're supposed to be building." That was my initial reaction is like, even if it doesn't take a lot of time you're not fully building out that edit screen.

It's taking some time and we want to get this other thing done.

I did have maybe a momentary thought of that but having now had some time to reflect and use it myself, I think it was a good decision for this particular project.

I'm kind of coaching a little bit because...

I will say the one thing that maybe was unusual or not our typical way of working is diving into the most complicated, highest value form to start with.

So by nature, you don't have all the setup and all the other entities that get built into a dropdown and filter stuff.

I think that's what caused this struggle.

And it's way outside the scope of this conversation, why that decision was made.

But I think that's part of it.

In this constrained situation, I think it was a good choice.

And, yeah, I agree we completely passed the point where it was reasonable to try to do all of it in seeders.

If you had four variations, do it in seeder.

But we had four different entities each with three variations that all layered upon each other.

It wasn't a realistic thing to try to do in a seeder.

And then what are all these 28 different logins I need now to test this one scenario?

Right. Well, and I think you hit the point. Reality there was two reasons why I kind of did this.

One, I didn't want to have all those seeders in there.

I didn't want to have to run that, I didn't want to have to keep track of that.

I didn't want to have to blow away all my data every single time to get new seeded data to go back to the setting that I wanted.

That was the first reason. The second is, I write perfect code that it has no bugs in it whatsoever.

Of course.

I also know that all users test every single permutation of all the code I write and they exercise

every single checkbox and every single interface on the user interfaces.

If that wasn't true though, which I know is absolutely true.

But if that wasn't true, another benefit I have here is I continually use my own programming and hopefully I'll find any inconsistencies or bugs before the user does, before they even get there.

Or you've been there too, where it is like there's absolutely no way that the change I made in this other unrelated section should break this other form, but it did.

Somehow.

And I hate when the customer and the client can find that.

But if I'm using some of that functionality through my day-to-day with my development stuff too, maybe I'll find that first.

That's just another added benefit.

And you were being a little sarcastic about the thoroughness and the perfect perfection of code and testing.

But, yeah, that was a side effect.

The other thing too is after we released this and it was being tested, something came up as it always does.

Some bug or something we didn't think about.

And we were actually able to use this functionality to kind of work around it and explore it in the testing environment.

So it did actually have a real-world benefit beyond just our ease of local development.

It was something useful to the people, the business, stakeholders that were testing this and giving this feedback.

So that's something else that sort of added to the fact that I'm like, "Yeah, this probably was the right decision, even though on paper it might have looked like a detour or a tangent." It was a necessary experiment to get to where we needed to be.

And you were very diligent in not scope creeping there.

Because one of those forms might have had 40 fields in the mockups.

We did the four fields we needed, we didn't go nuts and completely build out the whole thing.

Just enough to serve our purpose at this point in time.

So one of the things I kind of wanted to mention that hopefully everyone kind of heard in our voices

was the consternation and pain about this decision now.

And that's why I said, "Do as I say, not as I do," as a joke.

But this is one of those rare cases where we know there's a best practice and there's a bunch of things lined up, but the pain of doing it in that best practice in this one case was just a little bit too much, so we kind of went outside.

It's not like we destroyed everything and we went crazy.

Like you said, we only filled in a couple different fields and whatever.

But even talking about it now, you can see we're sure we did it right, but we're still questioning it.

We're trying to convince each other.

Yeah. And I think that that is something to keep in mind, too.

If you're considering doing something that is not in scope or not in a direction, you should feel very unhappy about it.

Because it's a thing you should really just keep an eye on.

Exactly. I have a scenario for you, Aaron.

You're okay in a public bathroom.

I'm not going to get too personal here.

First of all, no.

You just finished using-

Not... okay.

... the bathroom. You approach the sink, you're going to wash your hands.

Because I'm a gentleman and a good man.

Of course. What would you want right by the sink to assist you in washing your hands?

Like, if you could have a bottle of a liquid that was going to help you complete that task, what would that liquid be?

What do you think?

I think his name would be Jeff, and I would want him to give me my towel when I'm done and give me a mint and a spritz

of cologne as I leave.

That's after you wash your hands, I'm talking about before. You're approaching the sink, you have a faucet, right?

That's in the sink.

I assume there be some soap.

Okay. All right. It's such an obvious question.

And Jeff.

And Jeff. In what universe would you want hand lotion? Right on the sink, right beside the water.

Is there soap and hand lotion, or is it just hand lotion?

There are two bottles. Neither labeled, both identical.

Whoa. Are you sure that-

I am sure, I am sure.

No, I don't...

Yeah, it doesn't make sense, does it?

I don't like this at all.

And I guessed wrong. Let's just get right to it, I guessed wrong. But, oh, what is? This soap is weird.

This isn't soap. Why are there two bottles? I'll be more specific. I'll reveal my hand a little bit.

This actually was in a bathroom in a plane, right? This was flying back from somewhere and-

Oh, I thought you meant a public bathroom.

It is public.

This was in an airplane?

It was. Yeah, this was specifically in an airplane.

Oh, okay. Well, all bets are off, man.

You don't have a giant hole in the bathroom in a normal public...

Jeff's not going to be in there with you, if that's what you're saying.

Okay.

But to my point. Okay, maybe you're going to use the bathroom for some other purpose, I don't know what, and you want lotion.

It's dry on a plane, I'll grant you that. But still, I don't think it should be next to the sink where you put the soap.

I mean, I'm standing by that.

You are lucky this is a rated G podcast. Here's the thing, I understand.

Maybe you don't have the time like Joel and I have to bat around these decisions, and you just need it done.

Well, we can help with that. Head over to nocompromises.io and see how you can work with us on your project.