Maintaining conceptual integrity of the system during Maintenance

Question

While starting a new project, we kick start it based on what is "latest" and what is "known".

This includes selection of programming languages, frameworks in those languages etc. Quite a lot of time is spent on architectural design and detailed level design in terms of using specific frameworks and design patterns etc.

Things go on fine till we complete the development and push things to production.

Then comes maintenance (Defect fixes and Enhancements). People change, architects and designers moved out.

New set of folks who may not have any historical details of project are maintaining it now. They start comprising things on architecture, design principles etc. to provide quick fixes and adding enhancements.

This trend I'm seeing in many projects I've worked.

How to maintain the "conceptual integrity" of the system while doing maintenance?

Answer 1

1. Start with minimal changes.
2. Get into the style of the project.
3. Create islands of sanity.
4. Each commit has to improve the state of the code.

See this excellent screencast for an example of what can be done on legacy code without too much disruption.

Of course this requires management's commitment to a code-quality-first strategy to be able to make those fixes "right".

Answer 2

Maintaining conceptual integrity is difficult. It's an issue that needs to be addressed constantly during architecture, design, and construction, and it only gets worse when a project changes hands.

One thing that can help is for people from the original development team to be involved in the maintenance. Someone who already has an idea of the project's conceptual framework will be better able to keep to that framework than someone who is learning it from scratch.

Other than that, though, this comes down to the gigantic topic of best practices. Almost all "good" programming practices are aimed at ease of maintenance. Good design and construction practices lead to projects that are more easily grasped by later developers. Steve McConnell talks about managing complexity as the central imperative of software work. If the complexity is managed well up front, it will be easier for those who come later to keep the conceptual integrity of the project intact.

At the other end, good maintenance practices involve working against entropy. Keep the system under test. Don't decrease cohesion or increase coupling for the sake of a quick fix or a new feature. In fact, aim to make the project more coherent with each change that is made.

If the system was designed with extensibility in mind, then it shouldn't be difficult for maintenance programmers to keep conceptual integrity intact while doing their jobs. And even if it wasn't, it should still be possible for them to improve the project during maintenance rather than bring it down further.

If maintenance developers simply hack things together and do things the "easy" way, it will always degrade the conceptual integrity and increase the complexity of a project. Developers have to be aware of that, and they have to consciously choose the practices that will best allow them to avoid it.

The main idea is that maintenance should be a process of constantly improving a project, not constantly degrading it. An excellent book that deals with this topic is Michael Feathers' Working Effectively with Legacy Code. You might want to check it out.