> I can up-front say that the Raycaster needs to have fast data structure and that its worth giving up some performance to set that data up correctly. I don't

> I can up-front say that the Raycaster needs to have fast data structure and that its worth giving up some performance to set that data up correctly. I don't think this is a great example, really. You're going to want the brute force raycast working anyway for testing, and you're not going to know the details of what the right space partitioning approach will be until you a) understand the CSG application better, and b) have done some measurements. So it follows the 5 rules pretty well - the only thing I'd add is that you architect the system knowing that the data structures will change for representing the collections of objects and object/ray intersection paths etc. But your first pass should almost certainly be pretty simple and slow, and you should have your measurement code implemented and testing before you try anything sophisticated on the data side. Same goes for chunking up work across threads.