Have you ever cracked open a source member to make a simple modification, peered inside, and suddenly experienced that distinct sinking feeling in the pit of your stomach? If you're a maintenance programmer, no doubt you've experienced this sensation too many times, especially with homegrown code. How bad can it get? Everyone has horror stories.

Recently, I had this experience while attempting to make a simple change to a Lotus Domino program. Our company changed an account password on an FTP server, and suddenly this particular Domino application started to fail. From the outside, the simple solution to the problem appeared to be some internal reference to an FTP configuration profile record. I assumed that I would find the reference to the FTP server within an errant LotusScript, track down the FTP configuration profile record, and make a quick modification. However, once inside the code, I started to see some really bizarre things.

Nightmare from the Land of Cut-and-Paste

Instead of finding reference to a connection profile record for sending information to the FTP server, I found a nest of hard-coded IP addresses, user IDs, and embedded passwords within the LotusScript itself. In fact, within a single Notes form, I found this same nest of hard-coded FTP security information over 130 times, repeated line for line for each button formula in the form. The original programmer had, it seemed, cut and pasted a badly architected FTP LotusScript that had been found somewhere as an "example solution" from a Lotus Notes/Domino forum. The programmer had replaced the example IP address with our FTP server's IP address, user ID, and password and then repeated this button script throughout the application.

Of course, this meant that I had to track down every reference to the FTP server and laboriously fix the 130+ security flaws. My "simple fix" had transformed into a nightmare of code rectification, testing, and debugging.

"Qualified" vs. Best Practices

Who in their right mind would build an application with such blatant security flaws? One might assume it was an amateur Notes/Domino programmer. But it was not! The original programmer, who was now long gone, had claimed to have once worked for IBM Lotus and was a certified Notes/Domino developer. Yet this mess proved once again that a programmer's reputable job credentials will not guarantee that the working code is up to snuff. Instead, the price of re-architecting this particular code was left to the next poor dupe who came to the task of maintenance. In this case, it came to me, and it made me angry.

Programmers often spend a lot of energy within a shop establishing the particular standards that they see will be useful toward keeping a body of code in good maintenance form. Management, on the other hand, often has a difficult time understanding why good coding standards are so important. And while it is true that recent legislation for regulatory compliance has put increased pressure on management to ensure that corporations meet some minimum security and auditing standards, the actual internal code of an application seldom receives any kind of scrutiny at all. Moreover, as the number of programming languages and services has increased over the years, the foundation of actual code--often generated by code wizards and 3GLs--sometimes actually removes the visibility into poor programming practices. Sometimes, it even removes the ability to document what is going on under the covers.

Expanding Bad Coding Practices to Open-Source

Within the larger developer community, this problem can be further exacerbated by the distribution of open-source code. Open-source enables literally hundreds of thousands of programmers to contribute to projects that end up distributed to applications that are sometimes circulated to hundreds of thousands of users around the globe. Consider the recent security flaws that appeared in the Firefox browser: The code was distributed with flaws that were only later discovered by third-party sources. Was it bad coding or just a bug? When the application has been distributed to hundreds of thousands of users, who cares? Consequently, the need for standards in coding--better known as "best practices" for coding conventions--has become critical.

But who establishes those best practices? While certain software technologies, such as communications protocols and drivers, pass through international standards committees, establishing best practices for coding is still a relatively unbounded territory. So IBM's announcement last week (October 12, 2005) that it was releasing a subset of the IBM Rational Unified Process (RUP) to the open-source community was a coup for open-source developers.

Rational Unified Process as Best Practices

RUP is a vast collection of methods and best practices for promoting quality and efficiency throughout software development projects. IBM says that RUP has helped guide more than 500,000 developers around the world in projects ranging from small-scale products to large, industrial-strength systems. IBM hopes that donating the RUP subset will provide a foundation architecture and some Web-based tools for the software industry to further the process of establishing best practices for application development.

This is important to the industry as a whole because, according to some analysts, nearly half of the internally developed software projects run over budget, 90% are completed late, and 30% are ultimately canceled. In addition, an astounding 15% to 20% of all software defects actually reach the end user before they are remedied. According to the Standish Group, these defects are costing the U.S. economy upward of $60 billion a year.

Adoption of RUP as Model for Best Practices

IBM's donation is designed to advance a collaborative, industry-wide effort to synthesize, share, and automate development processes and best practices among independent software vendors, academia, the research community, IT organizations building integrated systems, and individual software professionals on small or large teams. According to IBM, if RUP is adopted, it could improve software development practices within organizations throughout the industry, while providing standardization in areas such as Web services and SOA.

According to Daniel Sabbah, General Manager, IBM Rational Software, "IBM is doing for the software development process what Eclipse has done for the integration of software tools, what Apache did for Web application servers and what Linux did for operating systems. Software practitioners at large companies, independent software vendors, systems integrators, and in government and academia will be able to collaborate more easily and drive better-managed and higher quality software projects. By rethinking software development practices to emphasize smarter processes and higher-quality outcomes, companies will reach new levels of innovation while obtaining productivity gains characteristic of an on-demand business."

Best Practices for the Future of Application Longevity

For the maintenance programmer hot on the trail of fixing a failed application, too often it's already too late to apply best practices. Too often the failing code is the result of a lack of standards or inappropriate practices, and the entire application must be re-architected and re-built.

RUP is, of course, merely one possible offering to create a model for best practices. Furthermore, many within the industry believe that RUP's complexity outweighs the benefits that it offers in establishing a model for best practices. But it's an important model nonetheless, and IBM's contribution to the open-source community will allow this model to be refined and developed according to the real needs of developers.

Yet the fact that RUP has been used with varying success by such a large number of developers in the past, on such a wide array of development projects, offers hope to maintenance programmers that there may be a brighter future for the task of maintaining code. If IBM's contribution has an impact on how software is developed, perhaps the next generation of applications that we are forced to maintain will offer fewer surprises, more flexibility, and better maintainability.

Thomas M. Stockwell is Editor in Chief of MC Press Online.