PoorMaintainability

The product is not as easy to maintain as it should be

Description

Typically, software products become harder to maintain as their life cycle progresses, until it takes a major re-engineering to allow reasonable success rates during maintenance.  Where the product starts life poorly engineered, this state of ‘ossification’ occurs sooner.

Discussion

Typically, software products become harder to maintain as their life cycle progresses, until it takes a major re-engineering to allow reasonable success rates during maintenance.  It may be cheaper to start afresh.  Where the product starts life poorly engineered, this state of ‘ossification’ occurs sooner.  Although poor documentation contributes to poor maintainability, the cures to that should be obvious, we do not address them here – yet remember, what we want is not more documentation, it is more useful documentation (see RecipientAlsoReviews).

Prevention, Amelioration, Cure

Traditional

Traditionally, the approaches to maintainability have been to do a good analysis, produce a good design with built-in flexibility, and produce clean, clearly documented code.  Once released, the processes of ossification start unchecked other than by major re-engineering.  The guideline “if it isn’t broken, don’t fix it” is used to slow down this ossification by minimizing change, yet in fact this approach exacerbates the problem.  If the code structure were changed to optimum for the change in functionality, the ossification could be halted and reversed.  Traditional software development approaches are not set up to do this safely.  One of the main causes of poorly structured code at first release is short cuts taken while attempting to meet a tight schedule.  SizeTheSchedule instead.  Any relevant approaches to avoid InappropriateArchitecture should be taken, and ensure the ArchitectControlsProduct so this architecture is implemented cleanly.

Modern

Modern Agile approaches tend to use SimpleDesign so there is considerably less code to maintain owing to the contained principles of “Once And Only Once” that removes duplicated functionality, and YouArentGoingToNeedIt that removes unnecessary functionality.  An underlying assumption in this latter approach is that we do not need to build in flexibility to permit future change until we need it.  ConstantRefactoring with its supporting techniques give the truth to this assumption.  The result should be a design that is always as simple and clean as it can be, even after many cycles of change.