Let's talk about more about code improvement. Some people seem to think that code improvement has a high associated cost. I think it only has a high cost if we're not very good at it.
R U doin it rong?
I’ve been writing lately in response to people who seem to think you can go faster by doing work that is less good. Probably at some high level of internal quality, polishing doesn’t pay off. I think if you’ll look at the code around you, though, you won’t find any of that over-polished code near by.
We have all been faced with code that is not as good as it might be. There are two issues: recognizing that there is a problem, and figuring out what to do about the problem. Both of these issues are skill-related.
From beginning programmer ... Expressive Names
An unskilled programmer may not realize that naming her variables pig, cow, horsie, and doggie is not a good idea. She does not know how to give them meaningful names because she has not yet learned how to create code that carries meaning. (I am not making this up. I knew this person.) This programmer will notice over time that she has to figure out over and over again what “mousie” means in her program. There will come a day when someone asking “What does that variable stand for” will get an answer. At that moment, if they say “let’s call it that,” she’ll take a step forward in skill.
A programmer of such low skill might focus entirely on giving things meaningful names. That will go a long way in improving the code, and it isn’t very hard to do. It doesn’t take much time to do and it pays off essentially instantly.
To intermediate... Duplication
A programmer of somewhat higher skill might learn to notice duplication of simple kinds, such as rape and paste feature implementations. There will come a day when they will say “I have to change this in five places now,” and if there’s someone there to explain to the programmer what a function, subroutine, or method is, he’ll take a step forward in skill. It doesn’t take much time to do and it pays off essentially instantly.
To expert... Does a change look costly? Look to your skills.
At every level of skill, there are changes that are easy to spot and easy to fix, that pay off essentially instantly. Clear code works sooner and is easier to enhance. It doesn’t take massive efforts to write code clearly, nor to make it a little more clear than it was.
Clean code skills, from the very simplest to the most complex, do not take much time, and therefore pay off very soon.
When a team wants to take enough time to clean something up that they feel the need to ask permission, it is a clear sign that they do not know how to solve the problem incrementally. This is an explicit statement that they do not have the skill they need to deal with the issue.
It may still pay off to make the changes, because they are hard (for these individuals) and maybe focusing on them will give them a better chance of success. However, I’m coming to think more and more that the answer should always be “No. But you can have tomorrow morning to start. Do that, check it in, and then let’s talk again.”