The Ambiguous Zone - Ben Northrop

submited by
Style Pass
2023-03-24 13:30:03

On the left is when we stay in our lane. We're given a requirement, we interpret the requirement, and then we make it so. Easy peasy. But what's that? The requirement didn't mention validation and it's a form submission screen? Must be it's not needed! We just do what we're told. And likely we're not this pedantic, but the point is that it's comfortable at this end. We get work done, and we don't make waves. If something isn't right, we were just following orders.

On the other end is when we go rogue. We find some "requirement" that might be useful (but no one really asked for), or some new approach or technology that's interesting or "hot", and then spend the entire sprint in our coding cave joyfully building it out. Will it actually help the project? Err...maybe? Regardless though, it'll be fun, because we love nothing more than smooth sailing - not being beholden to the ideas, thoughts, or reservations of others (well, that is, until they see our 4k-line pull request!).

Unfortunately, in neither of these states does valuable work get done. I mean...sure, something is produced, but it's rarely the right thing - i.e. the thing the users or the business actually needs. Because this "right" thing is really hard to figure out. It requires understanding the business context, priorities, and time constraints. It requires understanding the needs, preferences, and behaviors of the users. And it requires understanding the existing implementation and the scope and impact of what is to be built. All of this must be hashed through to get it "right", and this "hashing through" process is what happens in the Ambiguous Zone. It's messy and frustrating, but it is the only way to produce something of real value.

Leave a Comment