Lecture
Emergent design is a phrase coined by David Cavallo to describe a theoretical framework for implementing systemic change in educational and learning environments. It explores how the choice of design methodology contributes to the success or failure of educational reforms through learning in Thailand. It is related to the theories of situated learning and constructivist learning. The term constructionism was coined by Seymour Papert, under whom Cavallo studied. Emergent Design holds that education systems cannot adapt effectively to technological change unless education is grounded in the existing skills and needs of the local culture.
Emergent (evolving) design is a constant theme in agile software development, a result of the methodology's aim to produce small pieces of working code that deliver business value. With emergent design, the development organization begins delivering functionality and lets the design emerge. Development takes a piece of functionality A and implements it using best practices and proper test coverage, and then moves on to delivering functionality B. Once B is built, or while it is being built, the organization considers what A and B have in common and refactors, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile development release cycle, what remains is the minimal set of design necessary, as opposed to a design that could have been anticipated in advance. The end result is a simpler design with a smaller codebase. Practices such as tracking the vector of change have helped teams adopt Emergent design as a more systematic, disciplined, and pragmatic design philosophy.
In classic approaches to software development, an architect or team lead may design the system in advance. This can include all modules and communication layers, as well as all interfaces in the system. In theory, if you have enough time with the design and framework, development speeds up because all the features can simply be added.
This is rarely the case. In fact, designing a system entirely in advance to avoid risk results in a system that is inherently risky.
With Emergent Design, we begin delivering functionality and let the design emerge. We take a piece of functionality A and implement it using best practices and proper test coverage. We then move on to delivering functionality B. Once B is complete, we look at what A and B have in common and refactor the commonality, allowing the design to emerge. This process continues as we continually deliver functionality. At the end of our release, what remains is the smallest set of design we need, as opposed to a design we might have imagined in advance. In the end, we get a smaller codebase, which naturally has less room for defects and a lower maintenance cost.
Do not practice Emergent Design without a convenient suite of unit tests. Because Emergent Design relies heavily on refactoring, doing it without unit tests is an irresponsible practice.
Evolutionary architecture is an approach to building architecture that sets out to move forward in small steps while maintaining the pace of development.
At the heart of such an architecture lies the property of «evolvability», i.e. the ability of a software product to evolve over time without requiring a complete rebuild of the application.
Evolvability is usually defined relative to specific requirements. But it can be a property of the entire application.
Evolvability coexists perfectly with other «healthy» requirements. The main problem in software development is «anti-patterns», and evolutionary architecture is one way to solve this problem. Anti-patterns give rise to unhealthy requirements.
Evolvability depends directly on how the development process is organized and is impossible without setting up an appropriate development process.
At the code and application level, i.e. at the level of ordinary developers, problems are created by architectural, methodological, and organizational anti-patterns.
Comments