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.

I want to set up a scenario, because this is a real scenario we've been through more than once, and then talk through kind of our thought process. Because I think it'll be useful, we're not the only people that deal with this sort of challenge. Here we go.

We're brought in to take an existing working system and basically create a new version of it. I'm going to frame it this way, Aaron, and you can correct me if this is incorrect framing.

But let's say it's an app that's even been around a while, like multiple years, maybe even going on a decade. Like, it's been around, it's been functional, but it has a lot of challenges both in terms of like UI and how it's designed and access patterns and all this stuff.

So the company, for whatever reason, they made the choice that they wanted to start fresh, build something new, right?

Mm-Hmm (affirmative).

Then we talk about requirements. Okay, what do you want to build? I don't want to say clean slate, but we have a relatively clean slate to start from. And then they hand you requirements that are pretty much the exact same version of what they have, but maybe 3% better.

They're just kind of boxed into the current way of thinking because this is how the current system works. And then we're sitting there trying to interpret like, "Well, does this actually make sense?" Like, is this the right way to do it for the business?

Or is it just the way they're used to because their 10-year-old system does it that way? And trying to read between all of those different lines.

I mean, that actually sounds like a challenge, but a nice challenge. The other thing you ran into before too, is, we've decided there's a rewrite or the client has decided that.

So we come in and they say, "We'll make a new version of it better with all the newest technologies, et cetera. I don't have time to tell you how it works."

So there's no requirements other than just look at the old system?

No requirements, yeah. I mean, both of those are the same, either like too much or too much requirements. Or another thing is, actually, we both have had this scenario too.

Where it's requirements may be from the old system, maybe those are even out of date too by the time it was done.

Of course.

Then requirements for a bunch of future phases not split out from everything. So maybe the task is create new version that is almost like the old version, but can be missing some stuff.

So it's almost like an MVP of a new version, and then start to add on new stuff after that. But here's everything, but it's also missing some things, and here's some things that don't necessarily apply anymore.

Boy, I've given you some shivers here. And I'm torn because... Let's take the MVP example. We want to get something shipped that's useful in producing value to justify our existence.

You know, we don't want to go off into a dark hole for 18 months and then come back with the first version of this that they can use. Like, it'd be great-

Well, also because we'll get that wrong.

No, absolutely.

There's no way I can take requirements and build something for a year and a half and have done it right.

Yes, exactly. But we are focused on the MVP, like the thing that is essentially the smallest version that's valuable to the customer. But they're thinking longer term, right? They're like, "I'm investing all this time and energy, here's all the other things I want."

So I'm torn because I do like to have in mind what's coming down the road, even if it's version three or four, beyond what we call MVP, but also, is that actually going to be the requirement? Like, once we get through the first couple versions, is that still a problem?

Like, maybe they're trying to solve a problem that won't be a problem anymore. So it is hard to juggle having context of future needs without letting it overly color what you're about to build for the simpler version in the meantime.

I think I understand the problem. There's obviously no one size fits all solution. But do you have kind of like a framework or something that you use to, I don't know, delineate this or not lose track of the features? Or, how do you organize that?

Sure. The method I'm thinking of, and I'm thinking of some specific projects, but I'm trying to extract general principles from it. Is, first get agreement on what it is. What is in that first shippable version?

Because to me, that's sort of the North Star for what we're doing. If something is going to come after that and it's unclear, it may or may not be worth trying to figure out now. Like, if it has the feeling to me like, "Oh, this is really going to fundamentally affect how we build this MVP," I'll take the time to do it.

Otherwise, I'll write up a ticket using whatever tool the client's using to capture the information we have, to capture my questions, but then I'll tag it as like post MVP. So I don't have to think about it anymore, but I haven't lost sight of it.

Let me pose a argumentative sort of question then. I don't necessarily agree with this, but I want to explore it.

Mm-Hmm (affirmative).

If I have a client though that is giving me just so much information, so many requirements that are kind of maybe out of date and stuff, and I need to do an MVP, I feel a little deep down, and this is maybe my own bias, I'm not even going to be able to get them to agree on what's in an MVP.

Wouldn't it be more logical for me just to try to figure out the very first thing that they would need, no matter what, build it, and then sort of ignore the thoughts that they give me? And here's my logic, and I don't agree with this per se, but maybe.

Is, by the time I finish doing what I've done for them, the very first thing. Let's just say it's a user management piece, we'll have learned so much about each other and the process and the features that maybe all the things they had even thought they wanted, they don't need anymore, or thought about.

But then I'm like, "Well, people generally do know what they want to some extent. So am I being disrespectful that I'm going to ignore that?" But at the same time, I'm a human and I can only keep so much of this thought process in mind.

Yeah, there is a balance to be had. And I liked what you said, "You kind of learn more about the other person, not even just the project." It's sort of like you get a sense for how focused are they on what it is they actually want?

Or are there multiple stakeholders that kind of have competing ideas? Like, these are the things that you're not going to know in the first meeting or that first set of requirements. But I know you're setting up a potential argument, but I think there's an element of what you said I do agree with.

Which is, you don't have to figure everything out before you can start moving forward. So there are some things, like you might not know the exact shape of what MVP is. Even if you know 50% shape though, you can start working on that 50%.

And in parallel, that is why we work so well together. You know, one of us can be focused on getting those first bits of code and architecture in place, getting a feel for how people log in and what the navigation looks like. You know, all the basic stuff.

And then the other person can be fine tuning those requirements and kind of feeding each other back and forth. MVP, I think it'd be pretty rare to have a decision, "This is MVP, and it never changes."

Because every project I can think of, even when we thought we knew and we thought we had agreement, things came out later, it's like, "Oh, we actually do need that other thing." Or, "This has taken way longer, we don't really need it for MVP."

Like, there's always bartering that happens as you get going in the development process.

I think you just said a thing that kind of sticks in my mind too. I was thinking first of all when you were talking, it sounds a lot like the Agile workflow, like a real scrum. Like, you actually keep in contact with your stakeholders multiple times a week, which is pretty rare in my experience.

I love, that would be awesome if it was that collaborative, but it doesn't necessarily happen that way. But you said something about bartering which is there's that intermediate step, that intermediate processes. I know that not all of our clients will be as communicative, but that doesn't mean that you can't negotiate.

Right.

And you negotiate the scope and the process and all that stuff, even if they don't come back to you repeatedly. That was a nice point to add on.

And I will even... Because phrases or terms like barter and negotiate can sound confrontational or adversarial. And really we both want the same thing, we want to ship this. So the bartering comes in is like explaining trade-offs.

Like, "If you really need this feature, that kind of seems weird to me but you say it absolutely is critical, we're going to figure out a way to get that in the MVP but then maybe something else will have to go." So we're working toward the same goal, especially if there's deadlines or timeframes in mind.

But it is a give and take and it's just the reality of development. It's not just us trying to get our way on the project.

As usual, when we don't plan out the topic for the podcast, and we normally don't, it'd be on a bullet point or two. I kind of feel like we went all around, but what should we kind of take away from this?

If I had to distill it for myself. The message I hope that comes across is if you're in a situation like this, you are not a bad developer, and you don't have a bad client if some of these things are fuzzy in terms of requirements.

Especially with big system rewrites or modernization project. That's kind of the first thing. And then the second thing I would say is just have a collaborative approach where you're both working toward the same goal, you are making the progress you can, you're not waiting to have everything figured out before you start.

But you're moving forward, checking in, and iterating to kind of stay aligned on what the end goal is for that first version of the project.

Excellent. There's a lot of weird things that happen with our body, but there's a lot of things that I think it's nice that it shields us from that could be far worse.

I think about as I get older, my knees kind of crack. You know, joints can make noise and stuff like that. I am glad that that doesn't happen with our eyeballs.

That they crack?

Well, yeah. It is sort of like a little socket. Could you imagine if you could hear your eyes when they moved around? Like, how?

Oh.

It's a good thing there are certain things in our body that move around and like do stuff that we can't actually hear.

I agree a hundred percent with that. If I could hear my eyeballs moving around in my head, that would be terrible. Absolutely terrible.

There's got to be other... Like, I'm glad my stomach and all that stuff does what it does, and every once in a while, you hear it. But there's got to be more noises and things that could be emanating from my body that I'm glad aren't.

Well, the other one I think of is your heartbeat, because every once in a while, I'll hear that. Like, sometimes if you have like a head cold or whatever, you can hear it. Especially in your ears, and it drives me insane.

Like, I'm glad it's going. I am very glad my heart is diligent and pumping right now, but I don't want to know about it, I don't want to hear it.

Yeah. This morning, we had one of our regular dev calls from the Mastering Laravel Community. That was actually really cool. It didn't feel like a meeting, it was a nice chat.

I agree. And if you'd like to be part of that in the future, head over to masteringlaravel.io and check out our community.