Now that we have all these small problems we need to know where to start, here is where the architecture takes impirtance as it helps determine importance and the role of each little peace and that way decide an order of development, there are 3 questions in architecture you can ask yourself to determine the order of importance: Is it essential for the system? can you imagine the software without it; Do you know what it means? you better try to understand the feature from end to end before programing as it might interfere lather on; Do I know how to do it? if its a new area or concept to you, better learn what you have to learn before programming it. With these questions you can review each feature in the feature list and find the key features of your system, that way you have where to begin with, once you have the keyfeatures you can argument with your team of yourself with which to begin with, it doesn’t matter that much with which of them you start but its better to choose the one that reduce the risk more.
Other advices are to focus on one task at a time and only begin with the more important ones.
Some problems might require a Commonality analysis which is a path to add flexibility a similiar way as encapsulation does by searching whats things gets repeated and can get encapsulated in a function or object.
Only the beginning of the chapter was generic enough for me to consider it useful, when it began talking about the solution to each key feature the chapter was more like a guide to how to code a risk game, so I will not write more about this.
McLaughlin, B. (2006). Head First Object-Oriented Analysis and Design. Sebastopol, CA: Mary O’Brien
The Coding Manual 5000 