SDM should Advocate for Intention Revealing Interface
Me: Hey, did you attend the API interface review of your team?
Tommy: Nope, it sounded like a job for the engineers, not a SDM like me. Aren’t we micromanaging by getting into that level of design discussions?
Me: Ah, that's a common thought. But the truth is, your perspective as an SDM is invaluable for crafting interfaces that are genuinely intention-revealing.
Tommy: "intention-revealing"? Can you explain?
Me: Sure. In a nutshell, Intention-Revealing Interfaces from Domain Driven Design are designed so that just by looking at the method names or properties, you can immediately understand what that part of the system is supposed to do. No need to delve into the code or documentation.
Tommy: Okay, so like changing a generic update()
method to something more specific like updateCustomerAddress()
?
Me: Exactly! By making the name more descriptive, the interface immediately reveals its intent to anyone who interacts with it, including non-engineers. That's where you come in.
Tommy: How so?
Me: Well, engineers are amazing at figuring out how to do things, but they're often so close to the technical aspects that they might pick names that make sense to them but not to anyone else. Like, instead of securePassword()
, they might go for hashAndStorePassword()
.
Tommy: Ah, that second one does give away a bit about the underlying technology.
Me: Precisely. It's important to have interfaces that speak the language of the business domain, the ‘What’, not ‘How’
Tommy: That's an eye-opener. So my role would be to guide the naming and design to make sure it's aligned with business objectives and customer understanding?
Me: Bingo! You've got the big picture and the business objectives in mind, so you can help ensure that the interface doesn't just make technical sense but is also aligned with what the company and the customer actually care about. For instance, imagine you're dealing with a data synchronization operation in a big, distributed system. Engineers might think initiateDataSync()
is enough. But what if it's specifically about inventory? A more intention-revealing name might be synchronizeInventoryAcrossStores()
.
Tommy: That's a great point. synchronizeInventoryAcrossStores()
speaks more about what the actual business operation involves.
Me: Exactly! So never underestimate your role in this. You're the one who can help make these interfaces truly intention-revealing by bridging the gap between the technical and the business aspects. Remember, focusing on "what" and hiding "how" as much as possible makes for a stronger, more effective system. And that starts Intention Revealing Names in Interface
Tommy: Can’t wait to put this into practice. Thanks again for the valuable insights!
Me: You're welcome! Keep pushing for clarity and simplicity. That's how we elevate our game.
Last updated
Was this helpful?