Refactoring Theology

How Might a Refactoring Discussion Go?

2010-05-18T19:26:00.001-04:00

One bit of feedback I have received on this blog is that the discussions to date have had a very academic and abstract feel. I would like to address this by dedicating the next several entries to discussing practical and logistical matters related to Refactoring Theology and to provide some examples of how a Refactoring Theology discussion might play out in different settings.

This entry will outline how a Refactoring Theology discussion might happen in an informal setting. Ironically, many people engage in refactoring their theology without really being aware that they’re doing it. Imagine a small coffee shop setting. Three friends have gathered to partake of their favorite caffeinated beverages. This meet up is a weekly ritual for these friends, one that they jealously guard from intrusions by work commitments, spouses, and other social obligations. It’s a place where they share, argue, debate, and support one another.

Jeffrey is a graphic designer for a large software company in town. He is 24, single, and enjoys casual dating. While he identifies as Christian, he doesn’t feel bound to any specific denomination. He is fiercely loyal to his friends, perfectionistic about his work, but nonchalant about most everything else.

Carol is an editor at a small publishing house. She is generally easygoing but when in a serious discussion, she can be almost ruthless in her logic. She’s 26, married, and is what she calls, a “post-feminist”. Though socially and politically liberal, her religious life is fairly traditional. She usually avoids discussions of faith with most people.

Barry is between jobs (as is usually the case). While he did quite well in college, majoring in philosophy, he can’t quite find how to turn his passion for “ideas” into a means of regular income. Barry is an experimenter. He has abandoned much of traditional Christianity and is exploring Hinduism. He has just broken off a five-month relationship and is channeling his libidinous energies into early 20th century existentialist philosophy and video games.

It is 10:30am on a Saturday morning in early June. Barry and Carol have already claimed their usual table at Cafe-chino. Jeffrey enters, grabs his usual triple espresso, and joins his friends. After the usual small talk as well as discussions about Jeffrey’s latest girlfriend du jour, their conversation turns to a rather unusual topic: the Adam and Eve story. The “genesis” of this discussion was a local fundamentalist preacher who was demanding that the story of Adam and Eve be taught in the local high school along with evolution.

Clearly none of this group was on board with the good reverend. Jeffrey began the discussion by asking the group if there was any point to such a ridiculous and unscientific fairy tale. Carol, somewhat uncomfortably, did agree that the story of the fall had been used as a justification for the subjugation of women throughout history. But she wasn’t sure that the whole story was useless. She pointed out that most of the great philosophies were first expressed in fables and mythic stories. Barry agreed but stated that the difference was that the Bible stories are preached by the churches as true stories.

Barry, seeing an opportunity for a good discussion, began dissecting the story. He said that the first step is to try to understand the core message the author intended. “If the story is intended to be an exposition of the human condition, how could we extract the real meaning from the mythical trappings of the story? We could also read the story as an explanation of our relationship to the environment. I suppose it could even be the pre-historic version of Men are from Mars, Women are from Venus.”

Carol quipped, “If that’s the case, then my point is already made. The story is nothing more than the justification of a male-dominated social hierarchy where women are seen as nothing more than sub-human temptresses that seduce the heroic males to their ruin.”

Barry countered, “There may not be one single ‘point’ to the story. Remember that there were no publicists back then to demand that a work fit some sort of pre-defined genre.”

“No editors either!”, Jeffrey interjected with an almost flirtatious grin.

Carol responded with her trademark “look of death”. Then, addressing Barry, she agreed that they probably shouldn’t try to impose a 21st century literary process onto writers who lived thousands of years before The Chicago Manual of Style ever existed.

Jeffrey, feeling a little frustrated and out of his element, asked “So what do we do with the Adam and Eve story? If we don’t know why it was written, how can we figure out what it really means and whether than will be anything we can take seriously today?”

Barry thought for awhile and then added, “If I remember my literary history classes correctly, most of the Old Testament existed as oral stories for hundreds of years before they were ever written down. That makes it even more complicated because we have to look at how the writer told the story, which might be completely different from the person who first told the story hundreds of years earlier.”

Carol seemed especially annoyed at this insight. She replied, “Well that may be true, but we’ll never be able to know what this unknown storyteller might have been thinking. All we have is the story as it was written down. Let’s stick to that. If we do away with the sexist baggage people have added to the story, we could say that the story is about consumption, of wanting more and more, and how we all feed into that process and encourage others to do so. This leads to a ‘fall from grace’ which we could call the disconnection we have with each other and with the environment.”

Jeffrey looked almost in pain, his head spinning and his caffeine only now starting to hit his blood stream. “But that’s not what the story says. It says that God created an apple tree that he called the tree of the knowledge of good and evil. He made some arbitrary rule that nobody should eat from it. Eve listened to the snake and ate it, and then gave it to Adam. God got pissed and drove them out of paradise. How does this line up with what you just said?”

Barry laughed and made the observation that Jeffrey was as bad as the minister advocating that Genesis be taught in the classroom with evolution. “The only difference between the two of you is that he believes the story as literal truth and you don’t.” Barry sipped his coffee and continued. “You and the good reverend both are interpreting the Bible in the same way. The only difference is that you don’t buy into the story.”

“What Carol is doing is trying to look at the story in a different way. Instead of buying into every single element of the story as literal, historical fact, she’s trying to see what the whole point of the story is. The contextual elements of the story are there to communicate the truth, but they don’t have to BE the literal truth in and of themselves.”

Carol started getting more excited. “Yeah, I think we can all agree that God is outside of our perceptual plane and, by definition, is the source of all truth. So it seems reasonable that the truth could seem arbitrary to us. The apple might be a symbol of that which is seemingly good for us but in reality leads us to a state of disharmony with the world and to a disruption in our relationships.”

“But is that what the author intended to say?”, Barry asked with some discomfort. “This all sounds good and trendy to us, but is this what the author was really trying to say?”

Carol thought for a while and then said, “Maybe if he were alive today that is what he would say. It seems to me that to make this stuff meaningful we have to figure out the point of the story and then say it in as simple and straightforward a manner as possible. If we do that we can try to find the truth in the story and then try to apply it to our lives.”

Jeffrey agreed. “Well at least this keeps the old reverend from trying to rewrite the science textbooks. I wonder what he’d think of our little conversation.”

Barry chuckled. “He’d probably say we’re all going to hell.”

Carol had a wry look in her eye. “Hmmm. ‘Hell’. Maybe that’s a good topic for next Saturday’s conversation!”

Agile Manifesto - Part 4

2010-05-08T16:46:00.001-04:00

Note that this is the final installment of a 4-part discussion of the Agile Manifesto. I recommend that you read Part 1, Part 2, and Part 3 before reading this post.

The final value in the manifesto is “Responding to change over following a plan”. In some respects, this value is tightly coupled with the third value of collaboration over contracts. Both demand that the person place a premium on relinquishing control over the process and, more importantly, the outcome of the effort. In software development, the generally accepted wisdom is to plan, plan, and then plan some more! We are told that the more we plan, the fewer issues will crop up down the road.

As a project manager, I have been in the position of creating and maintaining elaborate plans that attempt to document the daily work of scores of developers over months or even years. Naturally at the time these plans are created, there are still many unknowns. Additionally, the client’s requirements may radically change. Since the contract is based on this detailed plan, both client and vendor can spend much of their time protecting their interests. Vendors need to maintain their margins and ensure that changes don’t compromise the quality of the deliverables. Clients need to ensure that their business and technical needs are met while meeting schedule and budgetary constraints. In the end, both client and vendor view change as the enemy. The plan becomes the golden calf of the project, and all the while critical issues affecting the ultimate success of the project are actively ignored.

This problem statement can be easily translated into the theological realm. When it comes to religion, humanity has an almost genetic predisposition towards rejecting change of any type. Even the smallest deviation from historical precedent has led to punishments ranging from excommunication to torture to even death.

The critical question is what to the IT and theological world share that causes similar reactions to prospection of change. In a word, it is fear – fear of what might be lost, fear of moving into the unknown without a safety net, fear that one might be moving down a path from which there is no return. Such fear initiates a primitive response in our reptilian brains that causes us to close ranks and to reject that which is unfamiliar. Refactoring theology, on the other hand, demands that we not only tolerate change but actually embrace it. Change represents the very dynamism that is what the Hebrew writers called ru-ach (spirit wind) and what the church has come to regard as the Holy Spirit.

In Part 3 of this series, trust is identified as a critical and necessary component of refactoring theology. This process cannot exist if those who are engaged in the conversation feel threatened or devalued in any way. If fear is to be reduced and managed sufficiently to embrace change, community must be established and respected. Can refactoring theology then be done in most church settings? Can colleges and seminaries embrace such a process as this? These are all good questions and ones that may be addressed in future postings. For now, the important point to understand is that refactoring theology requires the ability to embrace and welcome change. Change is inhibited in an atmosphere of fear. Therefore where fear is present, the ability to do refactoring theology is limited. Conversely, where there is a community that intentionally fosters trust and acceptance, the refactoring theology can thrive.

Before concluding this post, there is one final point to make. If I were to stop this post here, the process of refactoring theology might come off as a utopian ideal that could never be achieved in the real world. This is far from the truth. In fact, the need for refactoring theology grows out of the very fact that humanity is caught in this cycle of fear, mistrust, and alienation. Building these communities of trust in which to engage in refactoring theology does not mean that fear is eliminated or that all people are 100% unconditionally accepted. What it does mean is that there is the intention and commitment to stay true to the vision of this ideal while at the same time recognizing that such a state can never be fully achieved (Luther called this being simultaneously saint and sinner.). Refactoring theology does not require a perfect community of trust but rather a group willing to work through the process of building trust and to use this very act of trust-building as the momentum to begin its theological work.

Agile Manifesto - Part 3

2010-05-02T19:00:00.011-04:00

Note that this is a third installment of a 4-part discussion of the Agile Manifesto. I recommend that you read Part 1 and Part 2 before reading this post.

The third value of Agile is: "Customer collaboration over contract negotiation". This value gets to the core of the relationship between customer and vendor and is in my experience one of the hardest hurdles to overcome. It is difficult because in order for Agile to be successful, the parties involved must genuinely trust each other. While clearly there must be some sort of contractual document that spells out expectations, most traditional statements of work are so couched in protective language and so definitive in every specification that there is no room for innovation, creativity, or responsiveness to the legitimate evolution in the understanding of the overall software solution. Much of this is fear-based. Vendors fear that without iron-clad definitions around scope, requirements, and assumptions, the customer will force the vendor to do more work than was planned without cost or schedule concessions. Customers, on the other hand, fear that these same definitions are tactics by the vendors to only do the minimum amount of work, regardless of whether the solution will meet the customer's business needs. So, in the end, the contract negotiation process becomes a battle to assuage mutual fear and distrust by relying on the complexities of designing what is not yet understood and establishing delivery expectations that ultimately do not serve either party's interests.

So how does this apply to the process of doing theology? One answer to this question is to view the "contract" as a metaphor for the heavy-handed use of dogmatics as a tool to protect orthodoxy. While none of us can come to theology with a blank slate (nor would that be desired if it were a possibility), it is important to always check the impulse to reject out of hand a proposition simply because it strikes us as foreign, contradictory, or even heretical. People engaged in refactoring theology must have the freedom to explore any thoughts brought to the table without the fear of being shut down by arguments that appeal to either authority or tradition in a fallacious manner. This can be a difficult thing to put into practice, especially if discussing closely held beliefs, but it is essential if we are to separate the myth from the kerygma.

Another application of this value is by interpreting "contract" as social contract. Any practice, even refactoring theology, runs the risk of morphing from a means of change to an intransigent dogma. Those of us working in a refactoring theology model must be open to the evolution and adaptation of this very model as its process and practices mature and grow. If a strong social contract develops that constrains people from fully engaging in the questions before them, if sacred cows block the asking of any question, then the value of refactoring theology has been removed.

Refactoring theology must always feel a bit dangerous. If any of us become too comfortable with the process, then we're probably not doing it right! But to engage with others in such a "dangerous" activity, there must be an atmosphere of collaboration and trust between those engaged in the discussion. Even where there is disagreement, the welfare and value of the person, the preservation of the bonds of trust, must always be maintained. If any "contract" disenfranchises one or more members of the refactoring theology discussion, the discussion should stop and the group should reflect on what caused the breakdown of community and trust. Once this is resolved, the work can then begin again.

A Brief Note for Those Outside the Christian Tradition

2010-04-14T21:33:00.004-04:00

As a Christian, it's my intent to refactor Christian theology. This is my tradition and it's the framework that works best for to help me make sense of my place in the universe.

Having said this, I would like to suggest that there's nothing inherently Christian about refactoring theology. By this, I mean that I would very much be interested in the feedback of those from other faith traditions. It is my suspicion that one could refactor Islamic, Hindu, or Jewish theology is much the same ways that I am suggesting be done with Christian theology.

I will not attempt to do this kind of work, since I am not qualified to speak to these traditions. But I would welcome the thoughts of others who are part of other faith communities. How well do these process translate? What insights might be gained? Are there any parts of refactoring theology that cannot work within a specific tradition?

Agile Manifesto - Part 2

2010-04-10T16:55:00.046-04:00

Note that this is a second installment of a 4-part discussion of the Agile Manifesto. I recommend that you read Part 1 before reading this post.

This post will focus on the second value of Agile: "Working software over comprehensive documentation". In traditional software development, the team will first produce a set of requirements. Once this is done, the analysts will put together comprehensive functional and technical design documentation. In larger projects, this exercise can equate to thousands of pages of text, charts, wireframes, and flow diagrams - all this before one line of code is written.

It is not that forethought and design aren't important, but in today's fast-paced business world, by the time you get the documentation complete, oftentimes the business drivers and requirements have changes. It can then be a vicious cycle of change requests and document revisions, just to keep the supporting designs current to the needs of the organization. Another issue with this approach is that it starts with the assumption that business sponsors and users can fully anticipate their needs through an abstract documentation exercise. Many times, people need to work through real time prototypes in order to fully grasp what will meet their needs.

Agile addresses this problem by demanding that only the most fundamental and minimal documentation be created. Rather than taking months or even years to develop all requirements and design documentation, Agile takes the approach of segmenting the work into very small deliverables that can be completed in 2-4 weeks rather than 2-4 years. Each development period, called a "sprint", will result in a small piece of working software. Since there are no detailed design documents, the customer's product expert is embedded with the development team, and together, they design, build, test, and refactor the software. The results are something that not only meets the organization's immediate needs but also can provide an immediate payback to the company.

So how does this value apply in the process of doing theology? To answer this, I want to bring in a couple of concepts from traditional theology. First, is Luther's concept of theology from below. Luther argued that it a futile exercise to formulate a theology as if one could view existence through God's eyes (a theology from above). Humanity is incapable of such an insight, and any theology that starts with this premise is doomed from the start. Instead, he advocates what he called theology from below (meaning a theology grounded on what is within human perception and comprehension). Thus, he proposed that everything that a person needs to understand God is evident and accessible in the human person of Jesus of Nazareth. In essence, Luther would define divinity not as Jesus is who God is, but instead as God is who Jesus is.

The second concept I would like to touch upon is Rudolf Bultmann's process of demythologization. There are many misunderstandings around this process, and a full discussion of the topic is far beyond the scope of this piece. In a nutshell, his process begins with the understanding that the biblical record was written in an historical context that assumed a world view that we no longer share. Science was non-existent. Illness was thought to be caused by demons. In fact most every aspect of life was believed to be related to a supernatural cause beyond human understanding.

In order to communicate the message of Jesus within this context, the writers of the gospels who also shared this world view communicated their message in a way consistent with their understanding of the universe. In literary terms, Jesus' life and his divinity was only able to be communicated through the symbols available within this world view. Thus Jesus was borne from a virgin, walked on water, healed the sick, and made food appear from simple loaves and fish, etc. It was, to be blunt, a literary device that in the context of first-century people, was accepted and expected.

Today, many people of faith feel the need to somehow be twenty-first century people while still clinging to a first-century world view. Easy (and extreme) examples of this thinking are groups such as the creationists or faith-healers, who garner headlines by rejecting fundamental science in favor of a primitive, pre-scientific understanding of the universe. Of course, nobody in this generation can truly achieve the perspective of a first-century person. Instead, these people are conflicted hybrids, holding onto old perspectives for fear that they will otherwise somehow be torn away from God's salvation.

Bultmann promoted the understanding that people of the modern era must separate the myth from that which it is intended to convey. This is not (as many detractors believe) an invitation to rewrite a Bible free of all supernatural imagery. Bultmann is clearly on record against this. Instead, he stated that myth and the meaning behind the myth (he called this kerygma) must be taken together. The myth is the vehicle that communicates the meaning. Without it, you have a dry prose devoid of the depth of meaning contained in Scripture. So if you treat myth as literal fact, you substitute myth for meaning. If you remove the myth altogether, you lose that which communicates the meaning.

After this long digression, let me tie this together into the second Agile value "working software over comprehensive documentation". In the exercise of doing theology, it is important to focus on what works in our world and in human relationships. Scripture is a critical piece of it, but we do not use its world view to recast modernity into first-century Palestine. Instead we use the kerygma to develop theological understandings that work in our world and in our time. We cannot hope to, nor should we try to, develop a theology for all time. Instead, we should focus on creating short "sprints" of working theology for our context and our time. We can trust that as things changes, as challenges arise, and as knowledge increases, we will need to adjust our theological understandings. No problem. This change and evolution is a core principle of a Refactoring Theology - one that adapts yet retains the most simple and clear expression of the kerygma we value.

Agile Manifesto - Part 1

2010-04-08T22:11:00.002-04:00

As I mentioned in the post titled What is "Refactoring" and How Does it Apply to Theology?, the process of refactoring is part of a larger software development methodology known as "Agile". I would like to take the next few posts to discuss one of the earliest statements about Agile, the Agile Manifesto:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Over the next four postings, I would like to discuss each of the value statements listed above and how they apply to doing theology. The first value that we will discuss is "Individuals and interactions over processes and tools."

Most theological systems tend to be very process-heavy. By this I mean that they tend to by highly systematic usually involve complex patterns of reasoning. While there's nothing wrong with such things per se, Agile suggests that another approach might be more helpful.

In Agile software development, quality deliverables are achieved by small teams of people collaborating closely together. One variation of Agile, in fact, advocates that two developers share a single workstation and do what is called paired programming. This is where two people work jointly on the same code at the same time. The value of this and similar approaches is that collaboration produces better results.

Theology that's borne out of community is not a new concept. In the 80's Liberation Theology grew out of what came to be known as Base Ecclesial Communities. These communities, usually found amount the marginalized poor of Latin America, sought to re-imagine theology as a means to address the systemic injustices in their societies and the church. More recently, the Emergent Church movement seeks to formulate a theology and ecclesiology based on a corporate faith experience. It tends to distance itself from hierarchical church influences and instead looks to develop and share insights through local community relationships and even social media outlets such as discussion boards, blogs, and wikis.

Refactoring Theology shares many of these values. It also adds the practice of using these relationships to distill and crystallize theological concepts into that which is sustainable and extensible. In other words, it is not just a matter of being in community or in relationship. It is about harnessing these relationships to work together in the same way paired programmers collaborate. By struggling together to find clearer and simpler way to express a theological concept, not only is theology advanced, relationships and community are also enhanced.

Can theology be done in isolation? Yes, but it can be done better in the context of a collaborative faith community. This is the core of the message of Refactoring Theology.

What is "Refactoring" and How Does it Apply to Theology?

2010-04-04T22:21:00.001-04:00

Refactoring is a concept borrowed from Agile software development methodology. Without getting technical, refactoring is the process of reworking a program after it is debugged in order to simplify and streamline the syntax and logic as much as possible without sacrificing the required functionality. The theory is that too often, software is made needlessly complex because developers try to anticipate all future contingencies, no matter how unlikely they might be or because they borrow code from similar projects without removing the extraneous bits that aren't required. This complexity can, and often does, increase the likelihood of defects and makes the code much more difficult to maintain in the long term.

In short, developers have been trained to think that the more complex and abstract the code, the better it will be for the customer and for future extensibility. Unfortunately, this is more often not true. Studies have shown that the reverse is true. Developers can rarely anticipate future requirements accurately, so all the work and overhead added to the code ultimately serves no useful purpose and even hinders the evolution of the code when new functionality is required.

So, how are theologians trained? In systematic theology, students learn to work within frameworks that attempt to not only address the entirety of the cosmos, the human condition, and ethics, but to also be adaptable to any future ethical or social reality that may not, at that time exist. The result is a dense collection of theological arguments that must, in the end, get more nuanced and more complex as each generation's issues and realities challenge the systemitician's assumptions. Sounds familiar?

This blog will begin to outline a process that strives to create the simplest working theological concepts and then, as new areas issues and challenges are considered, find ways to apply them to the theology without adding needly complexity. In fact, the goal and challenge will be to find ever simpler ways of stating the theology without sacrificing the workability of that theology in all of its previous areas.

The process will follow these basic steps:

Identify the core necessary content
Develop a theological statement that meets this and all previously identified core content items.
Refactor (that is look for ways to simplify the expression of what has been stated).
Test to ensure to core content items have been lost or weakened.
Repeat at step 3 until step 4 is fully satisfied.

The key steps in a Refactoring Theological process are steps 3 and 4. Rarely if ever are theologians encouraged to build these steps into their process. The result, as in many software development projects, is a product that is unwieldy, unmaintainable, and destined to create more problems than it solves. The goal in Refactoring Theology will be to avoid this same mistake when engaged in developing theological insights. I will work through this in greater detail in future postings, but for now, this will serve as a brief introduction to the topic of Refactoring Theology.

Getting Started

2010-04-03T22:00:00.001-04:00

For those of you who don't know me, let me give you a little background (just a little). I am a seminary graduate who holds an Master of Divinity from Trinity Lutheran Seminary in Columbus, Ohio, USA. I was denied ordination from the ELCA due to their rules against ordaining openly gay candidates. Since then, I have been working in the IT industry. Perhaps because of the recent decision of the ELCA to open the ordination process to people who are in committed same-gender relationships, I have been having an increasingly strong interest in working through some theological thoughts in a public forum. This blog may be the beginning of this process.

I don't have any grand illusions that throngs of people will read this site. Perhaps nobody will. In the end, it doesn't matter. This is a place for me to work through my thoughts, structure some ideas, and try to integrate the technological and theological parts of my brain. I ask that anyone reading this blog consider that this is all WIP (work in process). Any resemblance to a coherent systematic theology is purely accidental!

An additional reason for using a blog to work this process is to impose some sense of accountability on myself. Even though this blog is not likely to endanger Blogger's infrastructure by overloading its servers, I do think that by hitting the "publish" button, I am making a commitment to be honest to this process. I don't know yet how frequently I will update this blog, but hope that by setting up this blog artifice, I will finally start organizing my thoughts.

In my next entry, I will explain why I have named this blog "Refactoring Theology". For those who are familiar with IT, the term refactoring will be familiar. So far is my brief search in Google has revealed, I don't think anyone has applied the term to theology - perhaps for good reason! But whether the term is familiar or not, I will explain in short order.

So enough of the prologue and on to the work at hand.