LightR/Experiences learned from ScalarR

-- From an Engineering Perspective

Don't design

Don't make your code suitable for every combination of strategies. Strategies are coupled by its nature, well-designed and highly decoupled code can get very messy because of one single awesome strategy.

Don't go modularized

Modularized design is your best friend. Modularized design is your archenemy. When it comes to a good strategy, exhaustive information sharing is the key to success, and yet the archenemy to modularized design. Don't go modularized.

Don't make abstractions

Abstraction is the core concept of software engineering. Good abstractions & standardized building blocks are essential to large scale software developing. But yet every single abstraction layer obfuscates the relationships between the top layer and the bottom layer, which makes optimization harder. A good strategy needs direct control into every single detail in the bottom layer, so don't make abstractions.

Do make really good abstractions

This does not conflict to the above. Abstractions are still essential because you don't make robots from sands. Kd-trees, math utilities, etc., these are really good abstractions and you don't make strategies into them. Decoupling is still good, so do make really good abstractions.

Accept messy code

If your math utility is messy, fix it. If your kd-tree is messy, fix it. But if anything else in your robot is messy, accept it. Good strategies are born to be coupled, because this way it leverages information best. So just accept it. It must be messy.