jonathanrobie
commented
4 years ago Given that definition, from the Concise Oxford English Dictionary, I'm struggling to believe we need to talk about whether Scripture Burrito is about ontology. (As it happens I took several courses on philosophy at university, and I like exploring the nature of being after a few beers as much as the next guy. Drinking beer is actually the only situation in which I think discussing ontology with engineers makes any sense whatsoever.)
Perhaps you could just ask what I mean by ontology? In information science, ontology has a different definition.
In computer science and information science, an ontology encompasses a representation, formal naming and definition of the categories, properties and relations between the concepts, data and entities that substantiate one, many or all domains of discourse. More simply, an ontology is a way of showing the properties of a subject area and how they are related, by defining a set of concepts and categories that represent the subject.
In other words, when I use that word, I am saying we need to clearly identify the things Scripture Burrito defines, how they are named, and how they are related.
mvahowe
Ontology [n]: the branch of metaphysics concerned with the nature of beingGiven that definition, from the Concise Oxford English Dictionary, I'm struggling to believe we need to talk about whether Scripture Burrito is about ontology. (As it happens I took several courses on philosophy at university, and I like exploring the nature of being after a few beers as much as the next guy. Drinking beer is actually the only situation in which I think discussing ontology with engineers makes any sense whatsoever.) And yet here we are! So
We have no hope of settling ontology for Scripture before the Eschaton
"The nature of Scripture" is reasonable shorthand for most fundamental theological debates that the church has failed to settle over 2 millenia. Christians do not agree what Scripture is. We don't agree about its scope (in a "number of books" sense). We don't agree about which of the myriad approaches to translation and paraphrase are appropriate. We therefore don't agree about which of these translations and paraphrases can be classed as scripture. But that's the easy stuff!
The really intractable theological debates are about "real" scriptural ontology. What is scripture for? What does it "do"? In which senses, if any, is it an authority? There's real potential for Scripture Burrito to dive into every one of those issues. Just part of one of those issues will be enough to keep us having "angels on the head of a pin" debates for the next century.
Deliberately staying as far away as possible from the ontology of scripture has to be central to our approach if we want to deliver anything, ever. We have to ride over the waves, rather than trying to drink the ocean.
And, yes, some theologians will sneer at the result, and call it superficial. That's ok. Theologians are paid to do that. I'm not.
"Everything anyone has ever done or might want to do with Scripture" is not a tractable problem
For much of history, Scripture was one of the main things people wrote about. The Bible is probably still the most published book in the world. Pretty much every technician who looks at digital Bibles says "How hard can it be?" and makes up a new way to mash up data. All this got worse (or maybe better) thanks to the Internet, big data and "deep learning" (another title that is crying out for deconstruction). And then every user finds ingenious, undocumented ways to subvert the technology to do things no developer imagined.
We cannot possibly represent all that in use cases. We can't capture even 1% of that in use cases. We can't even write the use cases faster than the world thinks up new uses. It's a "counting sand on the beach" type of task.
Use Cases are Just Another Discourse
There is absolutely nothing objective about use cases.
That's true, first, because of the previous point. We can't represent even a tiny fraction of everything, so we have to choose, and what we choose says more about us than about the topic we claim to be representing through use cases. So a spec based on use cases tends to be about as objective as those election videos where someome picks sentences from their opponent and strings them together to say something their opponent never said.
It's also true because how we tell a story is a large part of the story. As people interested in Scripture we really ought to know this. If you take a story everyone knows, and tell it differently, you may be killed in the street, as Steven discovered. Stories are a tool to "do" things. In the software industry, user stories are the equivalent of "and all my friends who I'm not going to name agree with me" at a church meeting.
Ultimately, what happens as a result of use cases depends almost entirely on how the stories are spun. Now I love playing word games, and I've had enormous fun with use cases over the years. But, if we want to actually agree stuff, I think just talking to each other about what we need to agree about is going to be way more productive.
Use Cases are just Really Bad Social Anthropology
Social anthropology is (more or less) the discipline of understanding others in their culture. Social anthropologists never reduce their findings to, say
"As a tribal chief, I want to have a bigger stick so my people will respect me more."
They don't do that because it's stupid and insulting to the victims.
Really capturing "user stories" is incredibly hard. People who do this for real spend years learning how to do it. Recording every single word that people say so that others can form their own opinions about it is just one part of the proper way to do this.
What we have in the software industry is social anthropology reinvented by engineers. We don't let social anthropologists build nuclear power stations, and we shouldn't let engineers do social anthropology. (Incidentally, most of Agile is social engineering reinvented by engineers, which is even scarier.)
Understanding Cultures Requires Interaction
Social Anthropologists don't watch a culture for a decade and then tell everyone how it works. For that matter, linguists translating the Bible don't listen to people for a decade and then write a dictionary. The only way to learn a language or a culture is through interaction. Talking about it, especially as an outsider, just gets you the stereotypes. You have to get involved. You have to try to say or do stuff in the language or culture you claim to understand. You have to do stuff.
Use cases as a first step are all about the delusion of being able to observe cultures from a safe distance and thus grasp the essence of those cultures. Social scientists moved away from that approach a century ago, because it doesn't work.
And, also, the more you understand, the harder it is to write the story for outsiders. The longer I live in France, the harder I find it to describe "What France is". That's not because I understand France less, it's because I find more ways in which there are no shared terms of reference with "outsiders".
Open Source Methodology Offers an Alternative to Fake Social Anthropology
Here are some of Eric C Raymond's 19 lessons from the seminal "The Cathedral and the Bazaar": (http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain)
Every good work of software starts by scratching a developer's personal itch. This quote features in SB 0.1 documentation. In our case I think it means that SB is always going to be what the people involved need it to be. We're not going to build a cathedral for the world because that takes centuries, and because we don't even know if the world wants us to build them a cathedral.
Plan to throw one [version] away; you will, anyhow. In our case, I think this means "Let's stop kidding ourselves that we're going to get this right in v0.2 or v1.0 or even v3.7."
Release early. Release often. And listen to your customers. In our case, I think this means, well, not taking a decade to discuss ontology.
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. In our case I think this means we do what we can do, and what we need to do for ourselves, and then we encourage others to tell us what we got wrong and what we missed. In other words, we stop kidding ourselves that all the wisdom is in our committee.
Smart data structures and dumb code works a lot better than the other way around. Hmm, I guess this would mean having more intelligence in Scripture Burritos?
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. Higher-level design does matter... but you find out what needs to change as solutions to specific problems. (That's the context of Raymond's entire argument.)
Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. ... in other words, in ways that were never going to be captured in use cases.
W3C failed to stop the rise of proprietary web standards, despite lots of ontology and use cases. Eric was involved in destroying Microsoft's browser monopoly by not doing ontology or use cases. Don't be like W3C. Be like Eric.
My Pantry
For the first year of married life I did most of the cooking. Over the years things have changed many times. Right now my wife and I both cook about the same amount. This is challenging because I have ideas about "my" kitchen and so does she. The photo above shows part of the solution. Things to note include
It exists. We're not still discussing kitchen use cases or the metaphysical nature of soy sauce. We didn't think that was a productive way to feed our family every day.
It's good enough. I have completed some impressive craft projects over the years. This is not one of them. I threw it together in a week. Some of the workmanship kinda sucks. If I started again, with an unlimited budget and unlimited time, I might do it differently. (Actually, that's a lie. In those circumstances I'd get someone else to do it.) But it's not going to fall down and it stores stuff and that's what matters.
It's a compromise. This is not my ideal solution. This is not my wife's ideal solution. This is a solution we can both live with.
It doesn't solve every problem. This would be a bad way to store fresh vegetables. I confess that I spent zero time considering the place of fresh veg in foodstuff ontology. I just used our existing vegetable rack.
We address new "use cases" one tin at a time. We never produced a catalogue of every product in the supermarket, and then of every possible packaging of every product in the supermarket, and then every possible way of storing every possible packaging of every product in the supermarket. We put up some shelves and put tins on them. When we get a new tin, we try to put it on the shelves. We might need to lay large items on their side. If things don't fit we put them somewhere else. Maybe if, one day, we end up with a pile of things that don't fit we'll consider moving some shelves.
Anyone wanting to revisit my pantry design should bring power tools. Really, I'm all for a better pantry. But I'm not going to be lectured about it by people who aren't going to make it happen.
A Realistic Way Forward
We start by scratching the specific itches of those in the room - if others want their itches scratched, they can join the conversation at any point.
We build stuff that works, we deploy it, we try to use it, we learn lessons, rinse and repeat, and we do that as fast as possible.
We expect changes to be expressed in ways that relate to our existing standards. Making use cases relate to our existing standards is out of scope. Someone with an itch needs to do that on their own time.
We don't expect anything we ship any time soon to be anything like the last word on anything.
If we hurry, we could still be relevant to the largest global Bible translation initiative in history.
In other words, we could just do what we agreed already, here:
https://docs.burrito.bible/en/develop/flavors/extending.html