Thoughts on Evolutionary Design

Jeremy, as always, has a lot of interesting things to say in his latest Train of Thought. I agree with most of what he said, in particular with evolutionary design, as Steve Eichert and I practiced it at Algo. It is important to not "allow your design thinking and abstractions get ahead of your development and requirements." It also important to postpone technical decisions until you actually need to make them,  The Last Responsible Moment. It's ok to rewrite and refactor and evolve the design. It's a natural cycle that matches how we learn the domain, as a team, together with Business.

That being said, all environments are not the same, and we did get in a position at Algo where we were doing so much evolutionary design and still a lot of things were missing due to constant reprioritization - the "tech" and "infrastructure" stories would always get postponed and never scheduled until we had to break me off from the team to handle them.

This all ties in with my friend Jim Shore's Design Maps and The Other Side of Design. There are two sides to the coin, Predictive Design and Reflective. Predictive is given a bad name as Reflective is the analyze existing code, find flaws, and refactor cycle, but as Jim shows with his Design Maps, neither approach is necessarily better than the other for all things. Successful systems *do* get built every day with Predictive Design as well as many fail. The important thing is to find *your* Design Map and work with  your team to find your team's map and use an appropriate mixture of design taxonomies for what you are doing.