- Introduction
- Maintaining Legacy Systems
- Maintenance of Software Is a High-Status Position
- Design for Maintenance
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Design for Maintenance
The way out of this mess is to design your organization for the effective maintenance of applications. Until you've refactored your organization to support your real needs, it's pointless to waste yet more money refactoring your applications. The following 12 recommendations are a starting point for a sane, maintenance-friendly organization.
Assess the planned economic life of your applications. Yes, some applications might only be needed for a year or two, but most mission-critical applications are going to last for a long time. After all, an application that takes 18 calendar months and 40+ developer years to create had better last for a long time. Planned obsolescence might be a good idea for a manufacturer of consumer goods like cars, but for everyone else it's just a waste of time and effort to continually have to invest in new versions.
Make your organization a great place for developers to work. Losing an experienced developer from a team is very expensive. Large mission-critical applications take years to learn, so it pays to retain the people who know the applications. The side benefit for the rest of the organization is that great organizations are less stressful and a nicer place to work.
Forget about the documentation myth—insist that the development team maintain their own application. Despite what the software engineering world has been trying to claim, software development is an intellectual learning process. The best people to maintain and enhance an application are the people who developed it in the first place. Whenever you're thinking about starting a new project, make sure that the bulk of the team is willing to commit for the planned economic life of the application. After all, it makes no sense to pay for two teams to learn the application.
Start paying maintenance programmers more than the people creating new applications. The way to attract good people into maintenance is to pay them. In the same way that lots of people jumped on the Java bandwagon for the rewards, once maintenance is hot, good developers will be attracted to it. Then the bragging rights will go to the maintenance teams with the best track record, rather than the dotcoms that are burning money playing with bleeding-edge technology.
Hire developers based on their experience with maintaining systems. Organizations have to get serious about hiring people who have experience with maintenance. Rather than looking at how many applications a person has developed, look instead at how many applications that person has supported—and for how long. Shipping the first version of an application is useful, but a developer learns many useful lessons by sticking around to ship the fourth and fifth versions of the same application.
Train your developers in all of your technologies. Developers who only know one technology are hazardous to the health of your applications. Your developers need to be familiar with all of the operating systems you use—mainframe, minicomputer, and PC. Cross-training is essential so that the developers understand the real issues that face your projects. Similarly, your developers need to be able to at least read and understand every programming language in use in your organization. After all, if you ever have to replace an application, the developers are going to have to read the source code for the old application to figure out exactly what it was doing.
Ask vendors to commit to long-term support contracts. Make sure that all of your vendors are committed to your technologies for the planned economic life of your applications. Where possible, make sure that the source code is available to you or at least held in escrow, so that if all else fails you can fix any problems yourself. Above all, try to make sure that a system that was planned to last for 20 years doesn't have to be replaced after 5 years because some software is no longer supported or a hardware component is no longer available.
Discourage the use of proprietary technologies. Proprietary technologies are a major source of legacy systems because sooner or later the vendor will decide that the product is no longer strategic or the market is not big enough. You might be really lucky and the technology will be purchased by another company, but, as the saying goes, "Hope is not a strategy." If you have to use a proprietary technology, choose one from a small, fiercely independent small company—such companies have a much better track record at providing long-term support than do the big companies. In the long run, though, your best bet is to use standardized or free software technologies, as both have good track records for both support and portability.
Design interfaces to avoid vendor lock-in. In the long run, standards do change, so design your applications with clean interfaces between the various components of the system. Getting locked into a particular vendor's technology is always a mistake. Use whatever proprietary technology makes sense, but make sure that if necessary it's possible to replace that technology with another. You never want to get to the state where it's cheaper to rewrite the application than to replace the database or the user interface.
Encourage your maintenance teams to do perfective maintenance. Rather than make the mistake of saying "If it ain't broke, don't fix it," remember instead that your maintenance teams have to live in the code every day in order to keep their knowledge current. Encourage the teams to perfect their applications. Let them adopt the motto "Maybe it ain't broke, but we can improve it." This will encourage a farsightedness that will allow the maintenance teams to adjust to new technologies as they arise.
Encourage your maintenance teams to experiment with new technologies. Your center of technical excellence should be your maintenance team. Encourage them to experiment with new technologies to see how they'll affect existing applications. By casting a net far and wide, they reduce the chances of being surprised by any new technology that shows up. After all, even the latest and greatest thing (such as web services) is firmly rooted in something older (like XML-RPC, which has been around since 1998).
Make robust, maintainable, and extensible software an explicit goal for all projects. Project teams deliver on what's important and downplay what's not important. It shouldn't be a surprise to discover that many applications that were developed in what used to be called "Internet time" are buggy, unstable, and practically unmaintainable. Okay, lesson learned—future projects need to have more appropriate goals.
Once appropriate team and organizational structures are in place, you can start to look at design and coding techniques that improve application maintainability. But that's a topic for another article.