In the world in product development, you have to expect the unexpected. Change is constant. And not little change, but gut wrenching left turns that no one saw coming. How do we deal with that? We have two options. We can panic and throw resources at the new challenge in an attempt to redirect the ship, or we can plan upfront for the unexpected, and make better adjustments when the changes land.
Most Project Architects and Project Leads try to design the best product they can in the fewest hours possible. This is basic business. The less cost to produce your product while maintaining high quality, the better the margin. However, profits and moral can be eaten up quickly if at the eleventh hour if you are doubling dev hours to adjust to new user requirements.
What to do? Plan for changes no one expects. And when I say plan, I mean more than just reserving a few dev hours here and there, you have to plan from last minute changes at the very beginning of the project. Before you write line one of code.
The best thing is design a system that accepts the product change. For example, when making a database call, you expect the return to have certain fields. What if suddenly, that one element of data is not there anymore?
Say you are expecting to get the cost of Widget X when you make your call. Now instead of the price of widget X, they are going to give you the cost of Widget X and the markup. Can you catch that change gracefully? What if down the line your code is expecting the cost of Widget X to calculate shipping? You no longer have this value.
Is your Architecture set up such that you can catch that value and refactor before it gets to the point shipping is calculated? And can you do that quickly? Remember, the due date for you product is bearing down on you.
What if your product depends on an outside source? Does your product fail gracefully if the 3rd party web service goes done? What if your product is ready but a partner site is not? Have you checked that you have a plan B for the user so that you can still release on time? If so you will be a hero to your client.
Another way to think about product architecture is to approach it from a modular perspective so that if one module fails or is not finished in time, the rest of the project does not fail. But more on that next time.