KeyholeMaintenance

The systematic practice of MakeTheSmallestChangeThatCouldPossiblyWork to achieve one's objectives with a code base, without stopping to so much as RefactorLowHangingFruit, let alone RefactorMercilessly.

This phenomenon has several common causes, but they are all usually rooted in the culture and process TheManagement choose to promote.

• Constant pressure to JustMakeItWork and then ForgetIt: essentially untempered FutureDiscounting.
• InternalQuality doesn't sell the product, therefore it has net negative BusinessValue because people spend time improving it.
• A shortage of people with both DomainKnowledge and familiarity with enough of the system. This can be due to too many people that JustLeave, hiring too many junior people because they're cheap headcount, or someone playing FungibleTeams or PlugCompatibleInterchangeableEngineers.
• Insufficient resources devoted to testing, whether UnitTests, AcceptanceTests or even plain old TestingByPokingAround. Typically there are only enough resources allocated for a single round of BigBangTesting and frenetic CodeAndFix just before the software ships.

One of the most damaging types of KeyholeMaintenance is expedient coupling of different parts of the system -- enough of this and eventually the modularization succumbs to the PlayDohPrinciple and you're left with a BigBallOfMud.

See also: OldCodeRusts