Half Done Is Enough

AntiPattern Name: Half Done Is Enough

Type: Management

Problem: Major enhancements or changes are required to an existing system with high TechnicalDebt.

Context: The system is high profile. New features are demanded. FailureIsNotAnOption. Organizationally, StrategicPlanning is non-existent or rarely adhered to. Senior management are watching.

Forces: Management face a plan and delivery timetable that look scary and risky. The scale of the change is very large.

Supposed Solution: Break the delivery up into a series of phases describing the transition from the old to the new. The completion of each phase marks progress towards the final end state where the old system or features are no longer used. The further increase in TechnicalDebt needed to fund the early phases will be balanced by the later ReFactor and clean up phases when the old system or features can finally be switched off.

Resulting Context: Management sees partial change as the end product. Work done during the early phases is GoodEnough for immediate business needs. Later phases are quietly discarded or descoped as more urgent work takes priority. Early phases may take longer to complete than initially planned, reinforcing the notion that there is insufficient time to complete the later phases. The development team is stuck with maintaining two parallel systems or sets of very similar features for extended periods of time (often years). Management doesn't understand why later changes are taking so long, despite the high maintenance burden. No time is allowed to actually complete the decommissioning of the old system or features.


View edit of July 29, 2011 or FindPage with title or text search