Kent Beck wrote First One, Then Many to explain the application of Succession to software design. Succession is a technique for evolving the architecture of a system from 'just enough for now' to what will eventually be needed. The example given is for a system that only needs to process one transaction today, but will eventually need to process many.
In general, the Extreme Programming community prefers simple design and architecture that evolves, as needed. Examples of this include:
In Kent's example, the client doesn't yet know how multiple transactions should be handled. While the developers could make some reasonable guesses about what type of APIs and infrastructure would be appropriate for processing multiple transactions, these guesses probably won't be optimal. The team and client pay the price for developing functionality that isn't yet needed. Additionally, the team and client will have to pay again in the future, either by living with a design that was created based on guesses, or rewriting the code to correct the design. Kent points out that there is also a risk that future developers will incorrectly assume that the code already has the capability to process multiple transactions, based on the API.
Kent prefers to create a minimalist design today, and then use a process he calls Succession to evolve it. His article describes how he implements a particular type of Succession, namely One-to-Many Succession, which safely takes the code from handling single transactions to handling lists of transactions.
Would you design and build the multi-transaction system the first time? Why or why not? Leave a comment and share your thoughts.
