How do you know which path to take? How do you find your glass ceilings? Unless you’ve been there and done that, you need to test your path to avoid significant do-overs. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)
Architectural Exploration
Beck writes:
The programmers should also experiment with architectural ideas — how do you build a system for multiple levels of undo? Implement it three different ways for a day and see which one feels best. These little architectural explorations are most important when you find the user coming up with stories that you have no idea how to implement.
My Thoughts
I’m a fan of testing multiple paths to find the best fit. I tend to call these “architectural spikes.” That said, before you test technical risk, make sure you first test the user experience. Nothing’s worse than implementing something that’s tough, only to find out nobody wants it. You can use slides or whiteboard walkthroughs to test user experience.
It’s also important to pick your battles. You won’t have time to test everything three ways, so ruthlessly prioritize your highest risks.
Key Take Aways
Here’s my key take aways:
- Implement three variations and pick the one that feels right.
- First nail the user experience, then nail the technical risk.
- Ruthlessly prioritize your highest risks.
Architectural Styles, Patterns, and Metaphors