Say you are a mechanics that specializes in customizing cars, even building them from scratch if the customer requires it. There is this customer that is back in your shop every so often to always put some new shiny thing in his super-sized limo.
Once he comes in to have a nice sound system installed. You diligently perform the task passing wires and connecting it all properly. He goes out a day later, he is happy and pays handsomely, as usual.
The next month he comes back but this time he wants a full blown home theatre installed. Once again, you take the limo in. Being a professional you revisit the sound system and make it easier to maintain by installing a tubing system for running the wires around the car. This way the wires are protected and easier to pull out and should you need to add more will also be easy to do. So you rip the old wires out, install the tubing and pass the sound system and the extra wires for the cinema, close it all up and you are done.
Realizing that the customer did not ask you to replace the old sound system you scratch off some of the cost of the replacements and of the tubes. However you still make money from the deal, Just not as much as you would have had you just threw the system together like you did the first time.
One month later he comes back, this time he wants a lighting system and he wants new speakers having damaged the old ones earlier in the week.
Because you kept everything nice and tidy you can quickly run the new lighting wires through your tube, install the system and replace the speaker. This time however you are done much faster, the re-factoring paid off by keeping you on top of your game.
Your competitor who was laughing at you for ripping perfectly good wires and installing all this extra tubing is still struggling to get his customer satisfied. Sure he was done faster than you most of the times but as time goes his customers are complaining that there are more and more delays and the overall quality of the work is degrading.
Looking at this you realize that your goal to not only stay in the business but to be the top gun is to balance what you do for filling the customer's demands and what you do to make your life easier down the road. Very rarely a customer will pay for both so you have to manage closely. You gamble that by pro-actively doing things right even at the cost of doing things twice you will keep maintenance costs at a controlled stable percentage of your productivity.
Software is the same, except programmers can play with digital duct tape for a VERY long time before the effects are truly felt by customers and managers. Unfortunately by that time the cost of re-doing things right grows exponentially with respect to how much duct tape is present and the average age of said duct tape.
This is why it is important that we keep re-factoring the system. Very often experience will show us new more efficient way to do the same thing or we can combine similar functionality and exploit redundancies instead of just copy past them. This is how we keep the system lean and mean. Time will show that constantly re-factoring the system to meet demands will keep productivity constant by controlling the amount placed in maintenance.
Placing duct tape will momentarily increase productivity at the cost of carrying a sub-optimal system. Technical debt is incurred whenever immediate productivity is favoured in detriment of the other aspects of a system. The debt analogy is good because just as interests over borrowed capital eat away the profits the borrowed time making things quickly incurs higher maintenance and increase the system fragility forcing a team to spend additional resources in maintaining rather than creating. Just like its financial relative, if the borrowing continues unabated most resources are spent towards interest repayment leaving very little for improvements. Technical debt will eat away technical resources to a point where most resources are spent just keeping the system running grinding to a halt all other possible enhancements.
So ultimately the questions is not should we or should we not do it but is it ethical to let managers and customers believe they can rely on productivity figures artificially bloated with the use of digital duct tape. Some would think it is a business decision but quite frankly this is so just because managers do not understand it. In the end, someone will have to pay the debt either though heavy re-factoring or by migrating to a new system. It is ultimately to us, programmers, to keep systems maintainable, you should not have to ask to re-factor as it is an inherent part of the job, failing to understand this is failing to understand what software engineering is all about. This said, I realize there are systems out there that have incurred an important debt already and paying off this debt will require decisions from the payers. Your job is such situation is to at least do your part to stop borrowing. This debt was incurred BY US maybe because we did not know better, because we were pressured to do it, still, we took on this debt and very often the people we handed the debt to do not understand it, thus cannot manage it properly.
Here's your software, all done, hope you like it.... Ho by the way, I maxed out your credit card doing it, hope you don't mind... cya