Write better requirements or pay for it later

So as a developer familiar with Scrum and Agile, I would obviously love to do stuff that way, but that's not always how it works.

Sometimes you get a bunch more requirements docs, like a waterfall.

So you end up getting a bunch of requirements, maybe pages, sometimes not.

But you get some sort of formulaic representation of what this next task is, or hopefully you do.

that you've written them yourself or whatever.

And then you can kind of look at that.

And I'm used to that.

I love that.

The more requirements, the better, because I know I'm building something out.

And that's really the skill set that we have as developers, too.

Anything that you can think of, human, I'm going to then make happen for you.

So I just need to know how you think, because how I think is different, right? I mean, that's what makes humans beautiful, too.

We all think differently.

So why that's beautiful is it gives us different ways to solve problems.

But where it struggles is any sort of thing you tell me to do, I'm going to think about doing it differently than you would.

And that's where these requirements come in.

Now, that's why we say to people, hey, right requirements, the more requirements, the better.

I know it's frustrating.

It's like, well, just figure it out.

Or doesn't everyone think this? But no, everyone doesn't think that way.

So there's kind of that's kind of my pitch is like I need requirements because I'm a smart person.

You're a smart person, but we think differently.

And so I need out of your head what you want me to build and then I will build it.

Yeah.

And I'm thinking a lot of the client engagements we have, like there's a business domain that maybe we are not super familiar with.