Refactoring analogies

One of the interesting sides of the software development being a relatively young profession is the lack of established mental models for different activities occurring in the industry. one of the effects is the use of the analogies to other human activities as a way of explaining software concepts.

Of course, the analogies are a tool used extensively outside the software profession. The difference I see, though, is that the software professionals use it to explain things within the community, rather than for popularizing their subjects outside the community. Doctors use rarely analogies to explain medical stuff to their colleagues. Physicists use analogies extensively to explain abstract theories like the relativity or quantum mechanics to outsiders, but not when talking to each other (Schrödinger's cat excluded).

Refactoring or re-writing of software components is one of the activities most difficult to explain within the software development community. There is a quasi-consensus that it is good, although only few people can explain why.

Although refactoring and re-writing are an obvious case of re-work many people go to great lengths in explaining the opposite, because lean teaches us that re-work is bad. This is where I think that the weakness of the analogies starts to show. The analogies break if you try to extend them too much. Lean concepts come from the product creation activities in the auto industry. While there is a lot in common between product creation process for cars and software, refactoring might be one of those cases where the analogy breaks.

Craig Larman has another analogy for the refactoring: it is like pruning your garden. In both you cut dead material to allow the growth of fresh branches. Do you think that this statement forces the analogy a bit? "Many new gardeners can't bear the idea of cutting back an entire plant, but this is tough love and your plants will thank you."

I have found that an analogy to crop rotation is a good way to explain the return on investment (ROI) for refactoring and re-writing. For example, product owners in Scrum can drive a high ROI features from a SW component for one iteration/release, but then they will have to accept lower ROI for the next period, because the component needs to be refactored. This is similar to planting clover after cereals or letting the plot rest. Usually you divide your software into multiple components, the same way farmers devide their farm into multiple lots. If you refactor often enough then you will not need to do it on all the components at the same time. You can drive your high ROI features from some of the components while not adding any features that touch components requiring refactoring.

The more you go without refactoring or re-writing the more painful it will be to do it. If you are lucky and smart you could find some low hanging fruits to pick during a massive refactoring. If not, you will just give a release for free to your customers. However, if you persist on not doing the refactoring at all, you will end up with a dead land that will turn into desert.