With this post I’ve taken a bit more of a practical turn compared to previous Post-Architecture posts: It’s more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
With this post I’ve taken a bit more of a practical turn compared to previous Post-Architecture posts: It’s more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
It goes really well with YAGNI. Also DRY without YAGNI is a recipe for premature over-architecting.
This is also one of the main benefits of TDD. There was a really good video that I can’t find again of a demonstration of how TDD leads you to different solutions than you thought you use when you started. Because you code exclusively for one single requirement at a time, adding or changing just enough code to meet each new requirement without breaking the earlier tests. The design then evolves.