Every so often, I forget myself and my no blame approach to team work. I hit the appropriate button in my IDE or Source Code client, and I find who to blame. It’s a wonderful term for which idiot wrote this line of code? and it’s a useful insight…
… on the whole, I’m not that bothered about WHO wrote the code, so much as WHY is the code the way it is. On the one hand, discovering the WHO can give me some useful feedback on how people in the team are doing, revealing areas where a little kind help might be required. Mainly, though, understanding who wrote a particular line of code and when can help identify the context in which it was written.
Sometimes, writing the best code is not the only answer.
Sadly, it’s almost always would be better to write the best code, but timing is still critical. There’s no benefit in polishing a low-priority module while higher priority, more impactful work is to be done.
On the whole, however, the net cost of NOT bringing something up to standard seems to be higher than the cost of making something excellent.
So what reasons might there be for leaving some code the way it is right now, or even… shudder… doing more of the same nearby?
Why It Should Be Left As We Found It…
- A new technique in a sea of other techniques is harder to read/maintain
- We cannot reasonably put a whole day’s refactoring effort, or more, into a 10 minute task
- There is not the test coverage or available manual testing resource for tolerating a deeper change
- Doing something small now, allows us to do something more impactful in a different part of the project now as well
These are great reasons and I’ve used them all. You can’t be perfectionist all the time. Perfect is the enemy of good.
But Things Will Only Stay The Same
If we want code to improve, then the above reasons must be the exception, not the norm.
Refactoring has a radius, which should allow us to make some incremental change. We probably have to accept there’ll be a diversity of styles of code for a while as things improve.
We need to be mindful of the constant drip drip drip of regretful code, and change it before we realise, with hindsight, that it’s been a horrendous avoidable cost.
Most importantly, we need to make a small incremental improvement at some early point in order to see future change.
Today I made the following tactical changes to some code I didn’t want to completely rewrite, but did want to improve:
- I migrated the tests to JUnit 5 from JUnit 4 – to allow me to write a future test I wanted to write in the style that would be easiest
- I refactored some coding style clunkiness out of the tests
- I retrospectively wrote a test I felt should have existed…
- … then using that test, I refactored the code it covered
- And again
- Then I modified some of the underlying behaviour for efficiency, covered by the new tests
These each took a few minutes and were reviewed quickly and easily. The code is not how I found it.
But when it was put into the state in which I found it, the priorities were a lot different. We must assume the correct decisions were made at the time under the circumstances.