If I could randomly choose any of you and ask them about a software project’s phases, they would probably say something like “analysis, design, implementation, maintenance, and decommissioning.” Of all of them, decommissioning receives the least attention, so I won’t say anything about it either. Today’s Coding Sheet is all about maintenance.
The developers and the system operators have a friendly discussion about an issue in production.
Many people think that all the meaningful work has ended when a project reaches the maintenance phase, and all that remains is keeping the system working.
Often, the team that writes the program is not the same team that does maintenance: the first team is called “development,” and the maintenance team is called “systems.” These two teams communicate only by sending compiled programs in one direction and sarcastic emails in the opposite direction.
When a project is set up like this, it’s tough to make changes after it goes to production. The systems team usually doesn’t have any programmers; if it has any, they don’t have the means to change the program. The development team can, but they are now working on another project, lack the time, the programmers who worked on it left the company, or some other excuse.
Many organizations fall into that trap after outsourcing the development and maintenance of their applications. If you ever wondered why every other Spanish government website looks like it came from 2005 and requires Internet Explorer 6 or Netscape Navigator 4, that’s why.
This doesn’t only happen with server-side software; it also happens with boxed software. Many projects have an “A team” that writes the new version of a program. When it goes out for sale, this team starts building the next version, while the current version goes to the “B team,” whose function is to fix bugs and compatibility issues. Typically, the B team has fewer resources and experience than the A team, so they achieve worse results.
To avoid this problem, many experts suggest integrating the development and maintenance teams. For the previous example, we wouldn’t have separate “A” and “B” teams but a single team that develops the new version while maintaining the old one simultaneously. This solution also has drawbacks, especially in terms of prioritization and assignment of resources to each project version. Still, it’s helpful to keep it in mind.
In the server-side software world, many organizations also integrate their teams. In them, the SRE group occupies the space that would belong to “systems” in other companies, but their role is broader. SREs are production experts, but they are also competent programmers who collaborate with the development team to monitor the application, make it scalable, and so on.
If you are interested, another term you can look up is DevOps, which integrates both teams even more, sometimes turning them into a single team. At the risk of repeating myself, “this solution also has drawbacks. Still, it’s helpful to keep it in mind.”
One way or another, I hope this Coding Sheet will encourage you to think more about your projects’ maintenance phase.
The illustration for this Coding Sheet comes from a drawing by Honoré Daumier.