Does this sound familiar?
- programmer:
- “We need to refactor this code…”
- manager:
- “Why?”
- programmer:
- “It’s horrible unmaintainable code!”
- manager:
- “But it works!”
From the outside, the idea of “clean” code or “dirty” code doesn’t make much sense. Code seems to be an entity with a binary quality: works/doesn’t work. Bugs might appear more similar to dust needing to be wiped from a surface rather than loosening duct tape that is barely holding everything together.
I’d like to propose a new way to communicate the multiple whys of refactoring to non-technical people.
Wikipedia describes a Rube Goldberg machine as:
… an exceedingly complex apparatus that performs a very simple task in a very indirect and convoluted way.
Something like that:
When requirements change and programmers start cringing it might be because they know that something simple like “make the light turn on faster” might require adjusting the size of the marble rolling down a slide or changing the color of the cat that gets scared in the process of a balloon popping.
John Panzer said:
Software Development is a knowledge acquisition activity, not a manufacturing activity.
Developing software involves some level of experimentation. During the course of development, programmers understand more and more about the problem they are trying to solve. Unfortunately, the first working solution they might put together will very rarely be the most straightforward or the most elegant.
Alan Perlis said:
Simplicity does not precede complexity but follows it.
The Rube Goldberg machines of software exists because the scaffolding of an application might work very similarly to the finished application.
There is a difference between “is it working?” and “is it done?”. That difference might well in the “how”.
Caveat: There are plenty of reasons not to refactor whether economical or otherwise. However, changes to an existing code base usually takes much longer than expected because of its not uncommon Goldbergish qualities.