Time and again, we witness, when a program goes into acceptance testing phase, the client and teams suddenly realize that the application is not meeting the Non-Functional requirements. Usually the application is very slow, or it is frequently going down or not scaling up as expected. I am not even talking of requirements mismatch here.
When client suddenly raises all these questions, all hell breaks loose within the development team. The team tries to find the hot spots and try to fix them. Invariably, I have seen the teams end only fixing the symptoms of the problem but not able to correct the problem. E.g if the application is making too many calls to the database. The quick fix at times is to cache the data. But invariably, this leads to problem in the future of cache invalidations and cache synchronization if the application is clustered. Remember, when we are fixing the symptom of the problem, we are only postponing the problem to a future stage (Technical Debt). All this means, with gating criteria's not getting met, cost and schedule over run becomes a norm. This becomes the most crucial phase of the program as the chances of program getting abandoned starts increasing exponentially. All this forms the long tail, as the program just keeps dragging on.
Focus on the Non-functional requirements right from day one is very important. Getting the architecture right at the beginning is very important, as the cost of fixing the problems keep on increasing exponentially as the application develops further and in the later stages it takes a heavy toll on every one. Techniques like Performance Driven Development is a good step in the direction. Other way to analyse each aspect of the requirement and design using the lens of non-functional requirement. At times, we as architects will be able to push requirements that do not meet the NFRs.