Factoring The Costs Of Refactoring
Most of the current IDEs and development tools have built in refactoring capabilities. This is OK as far as it goes, but they often cover up a much larger problem.
Some ways to make software development easier to manage with higher quality output is to think things through, document the requirements and approaches to solutions, and reuse what has already proven itself wherever possible. A kind of top down approach, the next to last operation is the actual coding, which should be a fairly linear and predictable process.
Documentation does not need to be elaborate; hand drawn diagrams on notebook paper works very well. We like to use whiteboards for the design dialogs and then take pictures of the results, for both specific details as well as overview storyboards.
Having simple documentation, with pictorial or any other graphical representation, has a number of individual advantages, and one big one: You’ll know when you’re done.
The need for refactoring, in most of its guises, strongly suggests that things were definitely not thought out, that architectural changes will inevitably drift in to the coding effort, and you’ll never really know when you’re done. Not reusing code also resets any learning curve back to zero, and assets already paid for will be discarded and then paid for again.
Refactoring also has a bad habit of introducing complexity. At first glance some repeated code sections may well appear as candidates for centralizing into one section. But far more often than not, the various possible instances will have slight differences that will be accommodated in the centralized section, resulting in it becoming large, cumbersome and, more damaging, having a convoluted interface.
The damage comes on the first maintenance pass, when the brilliance of implementation is forgotten. Bottom line is the not thinking things through and documenting them in the first place (see above) results in a higher development cost, due the additional time it takes to cull common sections for centralization, and much higher maintenance costs, that often are coupled with decreased reliability.
The old saw about paying now or paying later is certainly true, and of course later always comes with a high interest charge.
A Word From Our Sponser
Stop Toxic Email From The Bad Guys Before It Can Get Close To Your PC! Our? 
ePAL for email security is a barrier between the outside world and your regular email program
Tags: asset reuse, computer design tools, graphical design, program development, project management, software quality, Software refactoring