La separazione di responsabilità tra sviluppo e manutenzione software è diffusa, soprattutto in ottica di outsourcing.
Uno dei vantaggi della separazione, e del potenziale outsourcing della manutenzione, viene considerato il liberare per nuovi progetti di sviluppo (considerati come fonte di innovazione) risorse che altrimenti sarebbero assegnate ad attività di manutenzione (considerate come carico negativo che frena l’innovazione).
Ma la separazione ha pro e contro.
Robert Glass: Software Maintenance is a solution, not a problem
“In most computing installations, the people who do maintenance tend to be those who are new on the job or not very good at development. There’s a reason for that. Most people would rather do original development; maintenance is too constraining to the creative juices for most people to enjoy doing it. And so by default, the least capable and the least in demand are the ones who most often do the maintenance.
The status quo is all wrong. Maintenance is a significant intellectual challenge as well as a solution and not a problem. If we want to maximize our effectiveness at doing it, we need to significantly change the way in which we assign people to it.”
James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 pp.250-251:
“Some of the most powerful design insights come late in the design cycle, particularly during the phase we affectionately call maintenance. But traditional staffing profiles deploy the most skilled designers at the front of the life cycle, leaving the later phases to maintenance engineers.
Valuable architectural insight tends to emerge late in the life cycle as a result of having addressed requirements from concrete, successive problems drawn from a given domain.
It is at this late stage that a system can be refactored to consolidate design insight and to polish reusable artifacts.”
Pete McBreen: Software Craftsmanship, Addison-Wesley 2002, pp.167-168:
“Maintenance is the most important part of the life of any application.
Software engineering labeled the activities that take place after the initial release as ‘maintenance’, but this terminology is really just a hangover from the mechanical metaphor.
What is really going on here is a whole series of smaller software development projects – some fixing mistakes – but the bulk is either changing the application to meet changing business needs or making major functional enhancements to the application. This work should not be performed by a separate maintenance team. It is wasteful to train a new team of developers when you already have a team perfectly capable of doing this work.
Maintenance needs to be made a high-status activity.”
Mary and Tom Poppendieck: Implementing Lean Software Development, Addison-Wesley 2006, p.79
“Any code that is deployed will need maintenance, and sometimes separate maintenance teams are formed so that developers can focus on development and not have to task-switch with maintenance tasks. However, we generally recommend against this, because we believe that it is best for a team to remain with its product over the product’s lifecycle. Otherwise people may begin to believe that there is such a thing as “finishing” the code, which is usually a myth. Code is a living thing that will (and should!) constantly change.”