The refactoring dilemma
It is an accepted principle that you should leave working code alone. But sometimes you need to modify its behaviour. Now admit that the existing code is fairly opaque, that there are no tests and that the application has never been used nor tested extensively.
In any case, you will need to change. You could either
- introduce your change with minimal modifications
- refactor the existing code into something more understandable before introducing your change
The second option seems riskier at first thought. On the other hand, the ‘minimal modifications’ could turn out to have unexpected repercussions all through the rest of the application. In that case, the second option would give at least result in clearer code.
To determine which method is more efficient in a particular case, you could ask a programmer to try one approach and then another, but the result would be distorted because the second time round the programmer would have a better understanding of the code base. Alternatively, you could ask two programmers to attempt a different solution each, but it is unlikely that the two programmers would be of equal talent, so you would not get an answer about which method is better, but about which programmer is more experienced.
It is often suggested to add tests before operating on a legacy codebase; that often forces to adopt the second solution, since, in its current state, the application might be impossible to test.
Fluctuating requirements can contribute to the incertitude; but maybe, the whole situation represents an opportunity to take control and put your design hat on. How should this application work? What code is practical to write given the budget or time constraints?