Put optimisations towards the end

	I say this because somehow many people that I came across are extremely obsessed with optimisations.
While I can understand this I do not believe that this is the right way of writing software. For many 
reasons that would become apparent soon, my priority list is:

1) GOOD Software module/class design.
2) Simplicity.
3) Readability.
4) Well documented.
...
n) Optimisation.

1) GOOD Software module/class design.
	Design your class/module very well. Keep in mind that someone somewhere might eventually have to
use your class. Ensure that they have good interfaces available to them. Whatever happens the interfaces
that you provide the end user with must be consitent. If you add some new feature to your module it should
not become a taxing thing for your end user. For example if you had a member method called void Update(),
and suddenly you required an int as an argument ... good go ahead add it. However if this means that the
end user who had earlier used Update() has to change his code ... hmm either you have really messed up the
initial design or you did not have foresight. Always remember that the enduser has to be happy when he looks
at your classes. NOT curse you everytime he uses it. Also remember that the end user should not be forced
to read the whole design. He should only need to know the proper usage of the interface. This is where
documentation comes in.
	Also good software design will later help you with optimisations. You could have a function that reads
a file and gives you the pointer to first occurance of the word "Optimisation". However if you did not 
write a function but directly used that code in your module you could have problems while optimising.
Say 
	It also helps you shield from feature creeps. Suppose you had to store the list of all cars in
the game in a class and for various reasons you had decided to use arrays. However your feature creep
manager suddenly says that you cannot have a const number of cars because he saw this 'kewl' game with odd
car configuration and wants it in the game. Now if it means that you have to ask your fellow programmers
to change their code because you were lazy to provide them with an overloaded operator or an access function
for accessing the cars, then you really screwed up. It could imply a huge re-work.

2) Simplicity.
3) Readability.
4) Well documented.
n) Optimisation.

Copyright CyraX/Chaitany
http://students.iiit.net/~cyrax