Expectation-Driven Development
tl;dr An approach for breaking down a complex feature is to start from how someone with no context would “expect” it to work, and then work backwards from there.
DX, or developer experience, is a relatively new term that seeks to capture the ease-of-use that a particular set of tools, framework, or API offers. It’s analogous to UX, or user experience, but for developers, whose task in many modern apps is a relentless integration of internal tooling, frameworks, libraries and 3rd party systems.
Be “willfully naive”
I’ve been increasingly using the idea of “expectation driven development” when describing to other developers how they might shape a complex feature destined for internal use in a codebase. The idea is to mitigate bad DX in your tooling or systems by addressing a few points up front:
- start with your “expectation” about how a thing should work, and work backwards from there
- do not concern yourself with implementation details, performance concerns, etc.
- just… how would I expect this thing to work if I didn’t have any context?
If we do this. ie. start with where we want to get to and how a thing should work, it will often answer several implementation questions for you. You’ll see that a lot of higher-level things fall into place first (architecture, implementation, approach, etc.). Don’t be afraid to ask other devs for their thoughts and opinions, too. Sometimes expectations are very different, and that can be illuminating.
Also, by avoiding any implementation details, you can instead focus on the usability of a thing. Developing a nice structure for interacting with it (be it a component / endpoint / what-have-you) is paramount. Once that’s in place, you can then continue to iterate on the underlying approach, confident that on its surface it should be easy for other devs to work with or integrate against.