Premature Optimisation
Listening to a development discussion today I was struck by a thought on optimisation. We don’t just optimise software (for speed, size etc), we also optimise it for rate of change. In fact optimisation for improved rate of change is one of the fundamental contributions of the agile movement. After all refactoring , DRY, OAOO are not necessary if you never change your code (well, that’s not strictly true but it is enough of a truth for now). The discussion I was evesdropping on was about building a simple framework verses writing targeted code and I found myself rooting for the targetted code. At another time in the day a different group of developers were arguing about the whether to refactor some code they had just written or not. In both cases I felt that the arguments for refactoring now “It will be easier to change” and the arguments for the framework “it will be easier to incorporate new projects”, while factually true were not winning me over. The point was that the framework and the refactoring were optimising the ability of future developers to change the code. In each case the arguments were not winning me over because I didn’t think those areas would change much in the near future and the changes did add complexity (if only by adding a bit more indirection). So, the arguments were for a premature optimisation of the malleability of the codebase. Now we all know about premature optimisation, but I’m not sure we always think about it in the context of our process, rather than the codebase. So the next time someone want’s to improve the codebase “so it will be easier to change”, wait until you know what the change will be. You never know your luck, you might wait forever.