If It Aint Broke Improve It

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 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.


View edit of September 24, 2012 or FindPage with title or text search