The exact opposite of IfItAintBrokeDontFixIt which involves fixing whatever is broken. For a SoftwareEngineer, it may be better practice to follow this method, although it can lead to the SecondSystemEffect and FeatureCreep.

Is this also referred to as IfItAintBrokeFixItUntilItIs?

And if you break it while improving it, you can always go back to what worked before you started your improvement. -- DonaldNoyes
* ''One can go back sometimes... not always.''
** That is probably true most of the time for things not broken being fixed by more than one. It is different for those things done by a single individual fixing his own things.
* You can ''always'' go back. You can often also go ''sideways''. You are using VersionControl, right? (I swear, that should be the first thing they teach kids in school.)
** Even if you don't have version control, is having a simple copy of your code ''before'' you do anything risky too obvious a step?
** {Not if interacting with other systems and tools. It's difficult to "undo" such references and interface dependencies in systems that are part of larger or multiple systems.}

In my experience, most systems are tossed about every 15 to 20 years or so because some "new-fangled" technology makes them obsolete or the vendor gradually abandons the product. One should consider this before spending time "cleaning" existing systems outside of feature addition/fixing. (Whether they should be tossed or not is another matter; I'm just addressing the fact that they are tossed.)

''15 to 20 years?!  In some areas I'm used to seeing things chucked and rebuilt every 2 to 3 years.  5 year old code seems archaic.''

For internal systems? Usually nobody wants to spend money to revamp them if they are doing a satisfactory job, especially if they contain legacy data.

----
CategoryIdiom