Agile Process: Finalize the Architecture and Grow Slowly

Finalizing the architecture

After the referential implementation is complete, the starting team often has a lot of ideas about what should be improved and how to develop not only a really good solution but also the world’s best architecture. We have to balance the following arguments and decide how good will be good enough for our architecture.

Arguments worth considering

• Everybody would be proud to call their own architecture the best that has ever been developed, but the domain teams won’t profit from unnecessary flexibility.
• If the rest of the team has already been assembled, all the other project members are probably waiting to start their work. They probably won’t be able to contribute a lot to the discussion because they do not know much about the architecture built so far; therefore, they don’t know if they need a better one. They will, though, probably be afraid to start developing if the architecture is not stable (or finalized).
• The customer is more interested in functionality than in how great the architecture is, mainly because they will neither see the architecture nor directly benefit from it.

Although all these arguments should be respected, the customer’s lines of reasoning carry the most weight. This does not mean that we should never build anything in our system that is not directly visible to the customer, but rather that we should only build it when it is needed in the development of some functionality.

Fear of change

Allowing the architecture to improve can also provide a psychological problem. Developers tend to refuse to use something that is not yet finalized. They fear that all their effort will be thrown out if the architecture changes. On the other hand, the team cannot yet judge how much it might benefit from shaping the architecture itself.