Monday, September 27, 2004

Why Refactoring Is Fun

by Asim Jalis

I had another extremely positive programming experience today. There was a task that was estimated at 12 hours and we finished it in 4. There was a lot of refactoring and repositioning old code to make it do the new things that we needed to do. 1. I want to figure out what is going on here, why I am enjoying programming now. If I understand this I might be able to recreate this experience at will. 2. This figuring out is connected with a pattern I have noticed in INTP thinking (or at least in my own thinking). The pattern is that we extract general patterns from specific cases and then apply the patterns to new cases. In fact this paragraph is a neat example of the thing that it is talking about. We switch from general to specific and then back to general. A fluidity in beliefs and viewpoints makes this weaving extremely easy and almost natural. Let me call this the G-S (General <-> Specific) style of thinking. 3. So now I want to apply the same approach to determining why I am enjoying my current programming experiences so much. 4. I have been refactoring a lot. In fact refactoring has a deep G-S flavor. Elegant programs are fun to write, but programs with a lot of special cases are tedious to write. Except that when you apply G-S you can begin to see patterns in the tedium, and it can become possible to turn messiness into sublime elegance. The most satisfying programming experiences I have had so far have had this flavor: Initially the problem looks messy, but then once the variation between the different cases is subtracted out it becomes the manifestation of the same deep abstraction. 5. Mathematics has the same flavor of extracting out specific variation and then finally arriving at an abstraction that covers all the specific cases but also contains something more than the original cases. 6. Why is it so hard to get into this G-S state in programming? One reason might be that we are always in a hurry. There are deadlines to meet and tasks to complete. G-S refactoring requires pause and reflection. It's not possible in a frenetic work environment. 7. Another possibility is that some problems are more amenable to G-S reasoning and others are not. This worries me. 8. One reason I might not have experienced it before is that this requires a critical mass of engagement. It's not possible to see the opportunities for refactoring if I don't open the editor and study the program. 9. So there might be small steps that could be used to get initially engaged with a program and then once one is immersed in it to ramp up the engagement by refactoring it into elegance. 10. Another insight here is that it is usually much easier to refactor tests. However, once you refactor the tests that begins to suggest ways to refactor the code. In fact this might be the key to having the sweet refactoring experience. 11. This also explains why this experience is not possible in a hurry. When I am hurrying I don't have time to refactor the tests. And soon I don't have time to refactor the code.