Mike Dougherty wrote: > On 6/2/06, *Charles D Hixson* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Rule of thumb: First get it working, doing what you want. Then > optimize. When optimizing, first check your algorithms, then > check to > see where time is actually spent. Apply extensive optimization > only to > the most used 10% (or less) of the code. If you need to optimize more > than that, then you need to either redesign from the base, or get a > faster machine. > > Expect that you will need to redesign pieces so often while in > development that it's better to chose the form of code that's > easiest to > understand, redesign, and fix than to optimize it. Only when > development is essentially complete is it time to give > optimization for > speed or size serious consideration. > > > > That said, do you agree that some applications call for a 'ground up' > build mentality? For example, adding "security" after an application > is nearly finished is usually a terrible approach (despite being > incredibly common) That's not a "ground up" build. That's getting the design right before you commit to anything final.
I do agree that getting the security "right" should be done early. I would assert that it needs to be designed into the system rather than being patched on. The problem is that "right" is incredibly picky here. You need it not to be so cumbersome that the system is overwhelming either to compute or to use. And for any general purpose system it needs to be adaptable to a wide variety of circumstances, when you won't necessarily be able to predict in advance, e.g., what peripherals are available. (E.g.: you can't depend on visual recognition in low light environments, or if there might not be cameras available.) ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
