It seems an infrequent but common experience that sometimes you're working on a project and suddenly something turns up unexpectedly, throws a massive spanner in the works and ramps up the complexity a whole lot.
For example, I was working on an application that talked to SOAP services on various other machines. I whipped up a prototype that worked fine, then went on to develop a regular front end and generally get everything up and running in a nice, fairly simple and easy to follow fashion. It worked great until we started testing across a wider network and suddenly pages started timing out as the latency of the connections and the time required to perform calculations on remote machines resulted in timed out requests to the soap services. It turned out that we needed to change the architecture to spin requests out onto their own threads and cache the returned data so it could be updated progressively in the background rather than performing calculations on a request by request basis.
The details of that scenario are not too important – indeed it's not a great example as it was quite forseeable and people who have written a lot of apps of this type for this type of environment might have anticipated it – except that it illustrates a way that one can start with a simple premise and model and suddenly have an escalation of complexity well into the development of the project.
What strategies do you have for dealing with these types of functional changes whose need arises – often as a result of environmental factors rather than specification change – later on in the development process or as a result of testing? How do you balance between avoiding the premature optimisation/ YAGNI/ overengineering risks of designing a solution that mitigates against possible but not necessarily probable issues as opposed to developing a simpler and easier solution that is likely to be as effective but doesn't incorporate preparedness for every possible eventuality?
Edit: Crazy Eddie's answer includes "you suck it up and find the least expensive way to implement the new complexity." That made me think of something that was implicit in the question but I didn't specifically raise.
Once you hit that bump, and you incorporate the necessary changes. Do you do the thing that will keep the project as close to schedule as possible but may affect maintainability or do you go back to your architecture and rework it on a more detailed level that may be more maintainable but will push everything back during development?
Best Answer
What comes to my mind reading this is the agile adage: tackle the riskiest and/or least well understood tasks first within the project lifecycle. I.e. try to put together a working skeleton of the project as early as possible, to prove that the concept works. This in turn also enables one to run any sort of cruel tests to detect whether the architecture really delivers its promise under real life circumstances. Also, if there is any new, unknown technology / platform / tool included in the solution, take that early on the plate as well.
If the core architecture is OK, the individual functionalities can be added and tested incrementally, and refactored when needed, with relatively less cost. Needing to change the architecture is the big risk, which one should deal with upfront. This gives rapid feedback: in the worst case, if the whole concept falls apart, we know it early and can abort the project with minimal loss.