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?
Wednesday, April 14, 2010
Saturday, April 10, 2010
Agile Manifesto - Part 2
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.
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.
Thursday, April 8, 2010
Agile Manifesto - Part 1
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.
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.
Sunday, April 4, 2010
What is "Refactoring" and How Does it Apply to Theology?
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:
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.
Saturday, April 3, 2010
Getting Started
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.
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.
Subscribe to:
Comments (Atom)
