Whenever disciplines intersect, insights from the more established field typically inform the newer field. Sometimes, however, the younger dog teaches the older one some new tricks. After two decades in the software industry, some principles I learned there informed how I go about doing ministry. I thought these were general life lessons, but I’ve come to learn that many of my ministry colleagues were unfamiliar with them. So here is some software wisdom for ministry.

Patterns

In 1977, architect Christopher Alexander and some friends published A Pattern Language, which contained 253 patterns or solutions to common architecture problems when designing rooms, buildings or entire towns. Because the problems are perennial, similar solutions have arisen throughout history in different times and places. Each pattern describes a problem, and solution and specific examples of both. For example, consider pattern #167, Six-Foot Balcony:

  • Problem: Balconies and porches which are less than six feet deep are hardly ever used.
    • A balcony is properly used when there is enough room for two or three people to sit in a small group with room to stretch their legs and room for a small table where they can set down glasses, cups and the newspaper. No balcony works if it is so narrow that people have  to sit in a row facing outward.
    • Furthermore, a cantilevered balcony lacks privacy and tends to make people feel unsafe.
  • Solution: Whenever you build a balcony, a porch, a gallery or a terrace always make it at least six feet deep. If possible, recess at least part of it into the building so that it is not cantilevered out and separated from the building by a simple line, and enclose it partially.

This book is a great read as it is basically a one-volume architecture and interior design degree.

Four software developers who knew Alexander’s book also recognized that their own field consisted of similar common solutions to frequent problems. So in 1994 they published Design Patterns: Elements of Reusable Object-Oriented Software, simply known in the industry as the Gang of Four book (after the authors). They cataloged 23 solutions that seem to arise spontaneously again and again from the minds of the best developers as they tackle the challenge of designing good software. The exact implementation of the solution will vary from technology to technology, but the approach is transferable.

The identification and popularization of these patterns also shed light on anti-patterns, or popular solutions to common problems that actually cause more problems than they solve. Soon, symptoms of bad design (called code smells) were identified as early warning signs that you were going down a bad path.

I wonder if ministry similarly has patterns, as well as anti-patterns and their corresponding bad smells? My post on scaling spiritual formation is an attempt to articulate some of these patterns (as well as the anti-patterns they strive to avoid). Could there be others? To be sure, every context is different, and copying a solution from one context to another in a sort of franchise approach to ministry is ineffective at best and a vector of oppression at worst. But are there transferable heuristics or principles that can help ministry practitioners learn from the experience of others?

No Silver Bullet

In 1986, Fred Brooks wrote a seminal paper called “No Silver Bullet – Essence and Accident in Software Engineering.” Brooks explained that while salespeople will always promise that their tool will eliminate all your software creation problems, some parts of software development cannot be made easy. He proposed that there are two kinds of difficulties in writing software: accidental difficulties (things that in a perfect would would not be hard) and essential difficulties (things that are hard no matter what). While tools can (and do) mitigate or even eliminate accidental difficulties, the essential difficulties are almost impossible to reduce.

Consider the task of writing a persuasive letter. That was hard in the era of quill pens, it was hard in the time of typewriters, and it’s hard today. Improved tools (i.e. typewriters and word processing software) have eliminated the accidental difficulties of writing that letter. But you still need to actually compose a message that your audience will find compelling: the essential difficulty. All the grammar checking and fast, high-quality laser printing in the world won’t help with that!

Ministry is hard. But how is it hard? What parts of that difficulty are accidental, which could be reduced with better tools or techniques? What parts are essential – things that are just hard about ministering with people? Accepting digital donations eliminates an accidental difficulty for tithing – forgot to bring cash or a check? No problem! You can use your smart phone. However, no tool or technique can easily resolve the essential difficulties of ungenerosity stemming from fear of not having enough in the future or a lack of funds due to societal systems that reinforce poverty. Resist salespeople who offer you silver bullets for your ministry.

Traceability

Most big software failures – the ones where millions of dollars are spent and what is produced is simply discarded – stem from poor traceability. You can build the software right, but that doesn’t mean you’ve build the right software. When the system requirements that were gathered at the start of the project were incorrect or incomplete, or they change over the course of the project and the software doesn’t keep up, you can develop software that meets all the specified requirements but is useless for the business.

The solution is traceability. Everything you do must be traceable to a business need. The business needs generate requirements, which lead to a design, which in turn leads to lines of code. Similarly, every requirement should lead to a test which validates whether the software meets that requirement. In fact, the tests are usually created before the software is written! Educators call this backwards design, or starting with the end in mind. This laser focus on the desired outcome prevents unnecessary activity, and distinguishes true progress from mere action. We want effectiveness, not just efficiency.

What are the ultimate outcomes in your ministry, and the proximate goals that will lead to those outcomes? How is what you are doing day to day traceable to those goals? Look at how you are spending your money and staff and volunteer time: are those resources being spent in proportion to the relative importance of the goals they are working towards? Just because ministry is not a for-profit business does not make inefficiency and ineffectiveness virtues. True, some outcomes are hard to measure and there is mystery in God’s economy. Traceability simply helps us make sure that we expending our effort in the things that truly matter to us the most.