Defer When Appropriate; Commit When Necessary

Working with successively refined prototypes means that the architecture becomes iteratively more complete; therefore, certain decisions become more "baked in" and difficult to change. Remember the notion presented earlier: that the architecture should always be ready to answer developer questions. This means that whatever the developers work on first are the things that should be solved first. But that's a tautological statement, because you can probably arrange the development work to track the architectural changes.

The best things to start with are the riskiest things. They might be the exploratory aspects of the product that aren't similar to anything the team has worked on before, they could be the parts that interface with other software or other organizations, or they could be the aspects that will potentially have the highest cost. These are the aspects of the application that will most likely change, and where change...