Grady Booch defined software architecture as everything costly to change. This implies that the software includes some parts that are not so costly to change. However, if the project doesn’t have any buffer for changes, or when a “first-time right” culture is adopted, everything becomes costly to change, as every change will need escalation and approval, thus everything will become “architectural”.
This has several negative consequences:
- As often stated, people learn much better when they practice themselves, instead of just listening to others. This of course entails making mistakes in the early phases of the learning curve, and from those mistakes we learn. Without the ability to make mistakes, i.e. inevitable changes, no one will learn.
- The point above reflects itself directly in delegation. If less experienced colleagues cannot learn by making mistakes, they cannot take over any responsibility from the more senior members of the team. So, the senior members (project managers, scrum masters, product owners, architects) have to make all decisions big and small, and the project very quickly faces a scalability problem. For instance, since everything becomes architectural, i.e. costly to change, the architect has to take care of all the things, thus she becomes the bottleneck, and the project is slowed down to a crawl.
- The design exploration is severely reduced. In the simplest case you can just evaluate some alternatives on paper and choose one, this would hopefully still not count as a change. As it gets more complex you might have to do some simulation, prototypes or walking skeletons before deciding on the best alternative. In the ultimate complexity you need to get the market feedback to see the best decision. If changes are not welcome, you can barely do any prototyping.
- Finally, you cannot adapt to changing market conditions or technology. To quote from the Agile Principles: “Welcome changing requirements, even late in development.”
So, change is actually not some nuisance you should try to avoid or just cover against with some buffers in the schedule. It is good for your business and your team. The challenge of realizing a change-friendly culture in a corporate environment with yearly budgets and multi-year roadmaps remains. Ideas welcome :-)