A Person, Artist, Software Engineer, Geologist.

When do I know it's time to refactor code? Refactoring is different for every person but for me I follow these guidelines: - If I don't know / understand the code, I don't refactor.  Period! - Is the code broken?  If not then I generally don't refactor - Can the code be made much simpler?  If the amount of code can be reduced by 2x and made cleaner / simpler then I may refactor. - Can the existing code handle the new feature / bug fix?  If not then I may refactor. - I will not refactor the code if I think I have a better way.  Better my be for me but not other developers.  I leave working code working. Tests: I never assume that tests for existing code: -  Has complete code coverage (I've never seen this yet).  I've seen 100% coverage but not all combinations of logic or possible side effects of API changes, etc. - That the tests are even correct.  The tests only test what the developer wanted to test, not what could / should happen.  Tests are neve

My thinking toolbox consists of the thoughts that I have when designing and coding.  At a base level what I am concerned about is basically: Will this solve the issue? With others understand this? Can it be maintained and modified? Does this suit the issue? How can this effect other code or other developers? No matter what one does, whether one's deeds serve virtue or vice, nothing lacks importance. All actions bear a kind of fruit. - Buddha  Nothing that we do is without side effects and development is no different.  When a piece of code is designed or written, does it belong to the engineer that wrote it?  Will it ever effect anyone else?  How and why code is written can have far reaching effects down stream of it's creation. One of my concerns for any code that I write is if others can understand it.  My test for this is: Is the code the right complexity for the issue at hand.   Are there any hidden levels of indirection (think reflection, property files, re