Community-Driven Maintenance

Discuss the feature articles on the LDS Tech Home Page.
User avatar
Posts: 490
Joined: Wed Jul 18, 2007 3:38 pm
Location: Salt Lake City, Utah

Community-Driven Maintenance

Postby McDanielCA » Thu Oct 15, 2009 5:57 am

Community-Driven Maintenance was originally posted on the main page of LDSTech. It was written by Neal Midgley.

In June 2009, Nathan Dickamore wrote an article on this site entitled “Participate in Community Development”. He wrote about open-source advocate Michael Tiemann's theories concerning "exonovation" and how community-driven (and supported) projects yield better products. Similarly, by using the community's time and talents, the Church can better tackle the monumental task of maintaining its legacy data systems, free up developer resources, and utilize the broad range of technical skills available in the larger community.

As an open-source advocate, Tiemann posits that more project contributors lead to fewer outstanding issues. As a software engineer for the LDS Church, I lead the maintenance efforts for a large number of applications within the Supply Chain portfolio. These applications use a diverse set of technologies and require a relatively broad skill set in order to maintain them. Resources are sometimes limited, and we find ourselves supporting and maintaining more products than a few developers can handle. Indeed, often a project’s needs are put on hold as other issues take priority. In addition, it seems that for every issue we resolve, the customer uncovers one or two bugs or makes enhancement requests. As maintenance developers, we sometimes find ourselves sinking as we do our best to keep maintenance applications happy while at the same time developing new software to meet additional needs.

Some of these maintained applications fall into the category of legacy applications. They include those using older and less enterprise-worthy technologies, such as Microsoft Access and Visual Basic 6.0. Understandably, these products now receive limited support and are often trumped by farther-reaching technologies using the Church's Java or .NET stacks. We often find it difficult to balance our time between newer and legacy applications, especially while these legacy systems await system rewrites that take advantage of later technologies.

In addition to freeing up developers' time to focus on other maintenance issues and new projects, utilizing the community's help in maintaining the Church's software would tap into a vast and deep vessel of technical knowledge. Few people employed at the Church would consider themselves Access or Visual Basic experts. While most developers can plunk along the scripting sea of VB or VBA, some are often lost and must delay helping customers while they seek solutions to old problems. Sometimes, these legacy systems stop working after Microsoft updates or OS upgrades. Much time is spent helping these applications limp along until more robust software takes their place. In the meantime, Church developers often realize how much of the original developers' knowledge is lost or forgotten. Thus, these applications are not as effectively or efficiently maintained, especially when a select few are proficient enough to work with the older technologies.

By following Dickamore's thoughts about using community-supported development at the Church, we can solve many of the problems maintenance developers face, especially insufficient resources and lack of breadth of knowledge to meet dynamic and diverse needs. The community of LDS Church members who wish to aid the Church through community-driven software projects is growing. Community members are already compiling a list of feature requests and bug reports. Often such requests and reports are accompanied by suggestions and even offers to volunteer time. It makes sense to open the doors for community support of legacy applications.

By involving the larger community, as Dickamore and Tiemann suggest, we would be better positioned to pool the large number of developers required to stay on top of maintenance tasks, minimize the number of oustanding issues, and have access to a broad reservoir of resources with which to tackle any problem.

New Member
Posts: 38
Joined: Mon Sep 14, 2009 12:27 am
Location: Riverton, Utah, United States

Postby faazshift » Thu Oct 15, 2009 7:31 am

I strongly advocate opensource. Opening software development up to the community would definitely be a good move. It would highly increase productivity and generate a much higher quality product.

New Member
Posts: 33
Joined: Wed Jan 24, 2007 7:51 pm
Location: Riverton,Utah

Software Maintenance Costs

Postby dlongmore » Thu Oct 15, 2009 9:09 am

Yes Nathan/Cassie you are so right. This is certainly a worthy effort to accomplish "doing more with less". Software maintenance costs are much higher than expected. Not many developers want to devote their lives to maintaining an old legacy system. For one thing it does not look that good on the resume. One advantage of working on an old legacy system is that it will help the new developer gain a respect for maintainable code/systems. What lesson could be more important for them to learn. The new systems they are building now will need to be maintained later on. If they learn what not to do by working with a legacy system that is hard to maintain. Or even better learn what TO DO by working with a legacy system that is easy to maintain. I have maintained a lot of legacy systems and I can certainly attest to the differences. Let me know how I can help.

Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest