Comments on: The Maintenance Monkey

By: Dane Bounds

Dane Bounds — Sun, 08 Jul 2007 02:57:53 +0000

I worked at Church Headquarters from 1983-85 during the COBOL days. In graduate school and another programming job before working for the Church, I learned that maintenance was far more expense than new development. I believe they quoted 70% back in those days as well.

And observing the number of bugs in some of the programming products from Church HQ within the last 5 years, I’d say that CHQ abandoned the rigorous review process it used in the 80’s before putting new programs into production.

It’s ashamed we forget lessons learned and have to relearn them.

By: Anon Coward

Anon Coward — Thu, 10 May 2007 19:01:30 +0000

Speaking of “Think Quality,” I was highly surprised to find that in your own …/about-joel page here on your webpage, you are not following the Church’s style guide to capitalize the leading “T” in The Church of Jesus Christ of Latter-day Saints.

[Joel: Nice catch. The beauty of having a community to help out!! We'll get it fixed. Thank you!]

By: Joyce Conklin

Joyce Conklin — Fri, 13 Apr 2007 20:27:21 +0000

With all the enormous projects you handle (NewFamilySearch, for example) I just have to comment on the support section of your division. As a non-techie person at a stake Family History Center who has needed support more than once, I am greatly appreciative of the telephone help and the people working there.

By: Dean Davison

Dean Davison — Fri, 13 Apr 2007 20:03:53 +0000

It literally warms my heart to see that these issues that are huge problems in almost every IT organization around the globe, are being addressed within the Church. This problem is so common that it would have been naive to assume that it did not occur or simply look past it. I congratulate you.

By: Mario Hipol

Mario Hipol — Fri, 13 Apr 2007 11:24:17 +0000

I have always viewed this as part of the process. We actually utilize two systems for tracking. One system is for features and enhancements and the other is for defects and maintenance. What we are discovering is that it is extremely important to give the proper attention to both systems. We have noticed that users are becoming more and more aware of IT habits and our response process. If we procrastinate or don’t give proper attention to one list we begin to notice submissions with a “creative” description to make the other list that is getting our attention. I think that overall there isn’t quite the gap that separated “techies” from what was once considered casual users.

I think personal technologies have created a population that is very aware of how to get results from their staff.

At the same time though, it has also pushed IT staffers to move a little more quickly on projects before a “knowledgeable” end user comes along to circumvent your processes, create a “work around” or “solve” the problem themselves. When these situations arise, developers begin to lose control over the proper function their products and may end up never getting it back. I have seen many forums that are riddled with submission that say, “I was having problem (A) and I found a site that said to do (B) and now the application doesn’t work at all.”

I have to admit, I think I am guilty of that too.

By: Benjamin Hofmann

Benjamin Hofmann — Thu, 12 Apr 2007 20:31:34 +0000

We maintain about 125-150 web sites with a team of 14. We average about 70 requests per week–most of which are small. We also had the problem with people “shoulder tapping” the developers office as you put it. It seemed like nothing was being completed.

We’ve since changed things around and have two strong project managers who filter all requests. All request are submitted through our intranet and come to the project managers as enhancements. They then decide if the project is a bug or an enhancement or if it is a large request that needs a more formal project process. We still get people calling the project managers directly with urgent issues but we have successfully buffered the developers and our productivity has dramatically increased.

By: Steve Harward

Steve Harward — Thu, 12 Apr 2007 15:07:29 +0000

Great practices and reminders. Some of us are not blessed with large IT shops though and must fill the role of project manager, QA, and developer all at the same time. We have 3 in our small shop who’s customer base is both the company we work for (about 200 some employees) and the customers of the company (in this particular case the company is a government entity).

These circumstances may make a great excuse to not follow many of the procedures and processes you’ve mentioned here, but I feel that it makes them even more dire. It just means that we have to make sure we fill those roles and make sure they are individually and separately managed even though they are the same person fulfilling them.

It is so much more necessary that we prototype and clarify in the design phase because of limitations on our time once that phase is complete. It is so important that each step does not get overlooked just because the people performing them are the same people.

Maintenance still needs to happen, but hopefully it can be reduced by making sure that much of it is prevented along the way. As more “products” are produced for the customers that means less time for producing more products and more time for maintaining each new product. It is in our best interest to make sure that the “maintenance creep” is as slow as possible if we don’t want to become overwhelmed in a tidal wave of bug fixes and enhancement requests.

By: Sanford Loobins

Sanford Loobins — Thu, 12 Apr 2007 11:42:52 +0000

Excellent suggestion. Given your customer base at the LDS church. How do you gently say “no” to your general authority customers?

[Joel: General authorities are reasonable and understanding. Admittedly, people sometimes tiptoe around them when it's not necessary, but that's due to a respect for the office. General Authorities, like executives, desire and expect people to push back appropriately, to deliver bad news when needed and to offer accurate, timely information.]

By: Joe Nay

Joe Nay — Thu, 12 Apr 2007 11:37:43 +0000

Change Control Policies:
Might I add to the “Implement Good Governance” and “Allow (Force) customers to priorities”, that a strong change control policy, driven by the customer, will assist in the reduction of the “Maintenance Monkey”. I have found that customers often do not understand what they are asking for and that if you drive them to a change control board change requests that where once considered critical the customer will not even make it to a change request, if they are forced to defend the request to the board. The change control board will also reduce the number of request as they begin to see the impact and risk assessments of change requests and realize the true scope of what they are asking for.

I think IT shops get into a habit of not giving the customer enough credit for the ability to understand. This mistake is due to OUR faults in speaking in tech languages rather than in business languages. I agree that a good project manger, program manger, etc. is vital and should be on the CCB in an advisory position, but the CCB voting members should be customers with decision making authority.

[Joel: Couldn't agree more. Thank you!]