How to evaulate the design of a brand new applicat

Question

Recently I participated in designing & writing of an application which my team was given complete requirements and had to basically design and code it - it was about automation of 3rd party handwriting recognition platform to interop with a couple of our systems. Now a few months after the customer called with what seemed to be at first glance a minor issue, but after investigating it turns out that the whole application requires re-design just to fix this inaccuracy (it's easier to re-design then patched).

I personally don't think the application was particularly badly designed by any of this points mentioned on this thread but just that there was way to many small unknowns for us and looks like have now accumulated into a major design flaw - something we basically failed to see. All those small factors in the design stage seemed be insignificant & ignorable so we thought we are doing ok. Now with the problem occurred it it seems silly we couldn't spot it at design time but I guess we ignored some 'small' details & nuances which turned out to be significant after all.

So is there any approach to take when you are entering the design stage of an application the you are not too familiar with but it's design (falsely) seems to be more or less straight forward (create tables, write BOs, write UI etc) so that you can increase you chance to foresee this type of pitfalls in the implementation stage ( or at least certainly before customer deployment) ?

PS: Sometimes we hire experts to help like mathematician one time, or geographical guy another but who can help us incorporate a third party platform into ours except us

Answer 1

I think the approach must be to find the "best practices" in the domain. Each domain has procedures in which things had been done always; it's often forgotten by practitioner what the rationale for these practices originally was. As a newcomer, it is good to find out what these best practices are, and to follow them - blindly.

That way, you have a good chance to avoid making common mistakes, and if you do run into problems, there is a chance that these problems are typical for the domain, with well-known solutions/work-arounds.

All speaking in the abstract, of course.