More and more reports indicate that larger agile projects are running into design problems. In order to deliver functionality fast in small increments code gets written without too much thinking about overall design.
The code gets deeper and deeper in “technological dept” (I like that term), resulting in slower and slower speed regarding the implementation of new features, and increasing costs per feature.
Is seems to me that the term “architecture” is poopoed by proponents of agile methods, and it is being derided frequently as “big upfront design” that is never finished.
Even big names in software engineering are only very carefully suggesting (not to look like a SW engineering relic in an modern, agile world) that thinking about overall design before you start is not generally a bad idea.
I do agree with the statement that “big upfront design” often happens, delays implementation, and is never finished. But that does not mean you should have no upfront design at all, or that you should not write any code before the design is completely finished.
When you start implementing software without planning and agreeing on a general layout of your application (aka architecture) you keep adding pieces that eventually will form a structure, one way or another.
That structure could be called an architecture – some call it an “emergent architecture” – but isn’t that just a nice technical term for something that rather “somehow happened” opposed to “has been systematically constructed”?
Having a structure makes it much easier to guess where functionality has been implemented (in example, to fix a bug or add a feature), just like sorting a list makes it easier to find an item.
Sorting is an additional effort that doesn’t even change the items. But it adds information to the data that is useful. When you know the overall picture, it is fairly easy to determine where a puzzle piece needs to go.
The compiler is happy with anything that compiles; architecture is mostly there to help humans to understand how the system works and how it can be extended.
So: Architecture is there to help you to get the job done, not another bump in the road that needs to be flattened.
Do spend some time on thinking about architecture when you know enough about the requirements to do so.
Make sure that newly added code fits that architecture. Adapt the architecture if it doesn’t fit new requirements. Treat architecture like a feature of the system.