Goal number 1: a balance of maintainability/adaptability/discernability while trying to get a working program running as quickly as possible.
The quicker the "proof of concept" program (that will eventually evolve into the final product) is working, the quicker we can elicit overlooked requirements and identify unexpected potential stumbling blocks (or even unforseen/unexpected opportunities.)
As the program evolves, keep refactoring for maintainability/adaptability/discernability. And, wherever a segment of code looks like it can be refactored for better performance without worry of sticks in the wheels (i.e. new/changed requirements), then go for it if hurts too much not to improve the performance.
Once the program has evolved to a significant milestone that seems to cover the bulk of requirements and stumbling blocks, then start tackling code performance when it hurts too much not to refactor that code for better performance.
Something like that.
The quicker the "proof of concept" program (that will eventually evolve into the final product) is working, the quicker we can elicit overlooked requirements and identify unexpected potential stumbling blocks (or even unforseen/unexpected opportunities.)
As the program evolves, keep refactoring for maintainability/adaptability/discernability. And, wherever a segment of code looks like it can be refactored for better performance without worry of sticks in the wheels (i.e. new/changed requirements), then go for it if hurts too much not to improve the performance.
Once the program has evolved to a significant milestone that seems to cover the bulk of requirements and stumbling blocks, then start tackling code performance when it hurts too much not to refactor that code for better performance.
Something like that.