Over the years I’ve learned few things are more permanent than a temporary solution.
This is something your hear in a lot of places. Often (not always) it seems to be spoken with regret. I think we should be quicker to celebrate than a problem has been solved (and seems to be staying solved!) without worrying so much about whether it was done "properly".
Indeed, I think the frequent success of temporary solutions should be seen as a challenge to the prevailing orthodoxy that software developers should be striving towards more discipline and process. Instead, we should be looking seriously at why quick fixes and cowboy coding work so well, and asking whether we can apply these more widely.
In my experience, it is not generally a matter of putting some quick and dirty script in the solve a problem and it goes on solving the problem without modification indefinitely. It is more often:
1. Put a quick and dirty script in to quickly solve some immediate problem
2. When that quick and dirty script stops working, instead of putting a proper solution in place you either add another quick and dirty script in to plug the issue or you modify the original quick and dirty script in some ad-hoc way
3. Repeat over and over again
And then you end up with some impossibly complex Rube Goldberg machine.
I'd certainly agree that if a quick fix starts to accrete complexity, that's good evidence that it's time for a rethink. "ad-hoc modifications", I'm less certain about. How often is this happening? How much effort do the modifications take? Would the modifications still be needed given a "done properly" version (my experience: often yes). Would they be substantially easier?
It can go either way, and I'm certain not trying to argue that quick fixes should never be replaced -- just that trade-offs should be considered.
