| There was once a company that had an older system, with the all-too-common problems of poor design, instability, and difficult maintenance. The company decided to refactor the system's architecture rather than rewrite everything from scratch. Common code would be accessible from a new framework layer. Applications would use the framework layer for common services. This separation would allow framework programmers to gradually improve underlying framework code, with minimal impact on applications. The company decided to form a framework team. Application teams would rely on the framework team for common services. While this plan sounds reasonable, it's actually quite risky. If the framework team members lose touch with application needs, they can easily build the wrong code. If the application team members don't get what they need, they may bypass the framework to meet deadlines or slow down just to wait for what they need. Bypassing the framework is a return to the legacy architecture, while waiting for code is also a poor option. Evolutionary design provides a better way. It suggests that you: With one team, the framework and the applications can't fall out of alignment. With the framework driven by real application needs, only valuable framework code gets produced. Continuous refactoring is essential to this process, for it's what keeps framework and application parts separate. The company in this story decided to follow this evolutionary path, hiring coaches to train and guide them. Despite initial concerns about not having one team focus exclusively on framework development, the process resulted in continuous improvement in architecture, continuous delivery of high-quality applications, and evolution of a lean, general-purpose framework. Refactoring is the essential ingredient here. It's what allows the team to effectively and efficiently evolve a new architecture. | 
