Incremental design is about investing in the design of the system everyday, rather than doing all the design upfront at the beginning of the project (1). Its about designing the system for the requirements as they are known today and avoiding designing for unrequested features that may be needed (2). Incremental design is also referred to as evolutionary, simple, or continuous design (5).
The goal of incremental design is to keep the software flexible – that is, easy to change. This flexibility comes by keeping the design simple. This simplicity leads to code that is easy to explain, maintain, test and change (2).
Incremental design is in contrast to Planned Design (5) or ‘Big Design Upfront’. Planned Design (which is associated to more waterfall approaches) is about completing the design of the system before implementation is started. This involves working at a higher level of abstraction than writing code, usually using a language like UML to describe and design the system.
Assumptions on the cost of change
It is important to point out that the starting assumptions of XP and Waterfall in regards to change are quite different. In Waterfall, the assumption is that making design changes late in the development process is expensive. So a lot of effort is put into getting the design right at the beginning of the project. XP aims to flatten the change curve, and assumes that making design changes late in the development process is cheap. So XP advocates only investing in as much design as you need at the time. This is similar to Poppendieck’s principle of waiting till the Last Responsible Moment for making decisions (6), and the XP mantra of “You Aren’t Gonna Need It” (YAGNI) (7).
Kent Beck does point out that incremental design doesn’t mean no design: “The advice to XP teams is not to minimize design investment over the short run, but to keep the design investment in proportion to the needs of the system so far. The question is not whether or not to design, the question is when to design. Incremental design suggests that the most effective time to design is in the light of experience.” (1)
Incremental Design and Architecture
XP practitioners have different views on how how much design to do at the beginning of the project. One question that occurs in this area is : When is the best time to to make key application architecture decisions like deciding on frameworks and databases? Martin Fowler’s view is that “…there is a role for a broad starting point architecture. Such things as stating early on how to layer the application, how you’ll interact with the database (if you need one), what approach to use to handle the web server” (5). Indeed, evolving the architecture of an application via refactoring can be hard and require a lot of work as Jim Little points out(3). Neal Ford explores the idea of evolutionary architectures in detail (8)(9)
- Beck, K. and Andres, C., 2004. Extreme Programming Explained: Embrace Change. 2nd Ed.. Addison-Wesley Professional. Ch.7.
- Chromatic, 2003. Extreme programming pocket guide. O’Reilly Media. Ch.5.
- Little, J., 2001. Up-front design versus evolutionary design in Denali’s persistence layer. Methods, 3(3,245), pp.6-621.
- Shore, J., 2004. Continuous design. IEEE Software, 21(1), pp.20-22.
- Fowler, M., 2004. Is Design Dead? . URL: http://martinfowler. com/articles/designDead. html (Retrieved 28th Nov. 2016)
- Poppendieck, M. and Poppendieck, T. 2003. Lean Software Development: An Agile Toolkit. Addison-Wesley
- Fowler, M. YAGNI. URL http://martinfowler.com/bliki/Yagni.html (Retrieved 28th Nov. 2016)
- Ford, N. Evolutionary architecture and emergent design: Investigating architecture and design . URL: http://www.ibm.com/developerworks/library/j-eaed1/ (Retrieved 28th Nov. 2016)
- Ford, N. Microservices as an Evolutionary Architecture. URL: https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture (Retrieved 28th Nov. 2016)