- code complexity
- overall amount of work
- speed/time to production
- code obfuscation vs simple readability
- developer skill threshold for comprehension?
- extensibility
- modularity for reuse
- separation of concerns
- testability
- useful test boundaries
When architecting a feature, it’s important to ask “who’s it for?” While writing a code feature very quickly to please the client, it may damage the experience for future devs. On the flip side, architecting a feature with excellent test boundaries might be great for future devs (and ultimately the client), but it could ignore the urgency requirements of the client. By asking who we’re architecting for, we can gain clarity in what factors should be most important.