http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I can answer all of those questions at the same time: Train your team appropriately. seriously - if you have to ask these questions, you have serious trust issues in your team. train them or move them somewhere else. http://ayende.com/3848/trading-safety-for-simplicity#comment3http://ayende.com/3848/trading-safety-for-simplicity#comment3Thu, 05 Feb 2009 21:33:50 GMTAll 'bugs' are not equal. If a high level of [runtime] validation complexity is required to prevent a 'bug', then I would say a side-by-side evaluation and prioritization of any such known 'bugs' would be in order before addressing them. Such an evaluation should be based on the cost of likely downstream consequences. Those costs should dictate which 'bugs' are tackled and which are not. I would also say Stephen is pretty much on target and if there were very many high-cost API 'bugs' were appearing I would want to review the architecture, design, and implementation of the API - something is probably fundamentally amiss. Either that or you've wandered into a complex and expensive problem space. http://ayende.com/3848/trading-safety-for-simplicity#comment2http://ayende.com/3848/trading-safety-for-simplicity#comment2Thu, 05 Feb 2009 18:16:01 GMTOne of our goals with developing apis is to try to ensure that errors happen at compile time vs runtime.. I think this is the exact thing that can go way to far and make an api really ott.. we basically cut the code base of one of our 'incubation' projects in half when we went to release it.. whilst making it more flexible as well. http://ayende.com/3848/trading-safety-for-simplicity#comment1http://ayende.com/3848/trading-safety-for-simplicity#comment1Thu, 05 Feb 2009 17:16:11 GMT