If it is Working Don’t Touch it?
Occasionally I hear this sentence from here and there.
Every time I hear it I get angry again. IMHO, when someone says that sentence
it’s probably indicating that there is a lot of pain coming at us in the future.
When I always hear that sentence?
- When there is a spaghetti code that nobody knows how to deal with (because
the code is so tangled).
- When the developer is lazy and don’t want to change something that is
working even though it is badly written.
- When there are no unit tests that will imply that changes you made broke
- When managers/developers want fast delivery and don’t care about code quality.
- When no one knows what is going on in some piece of code (or don’t care).
- And more. You name it.
Even though it is probably implies that I’m always touching the code and change it,
this is not the case. What I want to say is that code changes during the development
and maintenance cycles. You need to refactor smelling code even though it’s working and
not keep bad code. If you have poor design or spaghetti code it will come at you in the
future and then to refactor the code will be horror. So if you see something that isn’t
right it’s your responsibility to fix it or at least to report about it.
For example, last week I showed a piece of code that I wrote to other colleague.
During our conversation I saw a method that was bad written and fixed it.
Since I had unit tests for my code I could see that my changes didn’t break the application
and now it’s running faster.
So the lesson here is – if it is working and smells touch it!