Lessons from Software Engineering for Bible Translation

Lessons from Software Engineering for Bible Translation

(Jos, Nigeria)

Some time I may get round to writing a paper on some cross-disciplinary lessons that Bible translators can learn from Software Engineering. (This is essentially trying to integrate my former and current career paths.)

My attention was caught by a slightly overblown headline on favourite irreverent geeky news site The Register: Most developers have never seen a successful project. Let me intersperse some quotes with some comments on how I see this relating to difficulties we face in the Bible translation world:

Most software professionals have never seen a successful software development project, continuous delivery evangelist Dave Farley said, and have “built careers on doing the wrong thing”.

Talk to many a translation consultant and you’ll find a lot of stories of dysfunction and everything going wrong. Of course it depends what you consider ‘success’ and ‘failure’ to be. The speaker here – who obviously has his own business agenda… but he could still be onto something – isn’t saying that most software professionals never get their projects finished or issued. In fact many projects are launched but then lurch from difficulty to difficulty, being made to work because they have to.

Farley, kicking off the Continuous Lifecycle conference in Mannheim, said study after study had shown that a small minority of software development projects could be judged successes.

One study of 5,400 projects, by McKinsey and Oxford University, showed that 17 per cent of projects were so catastrophically bad they had threatened the very existence of the company.

It has to be said this would be the case with the Igbo Bible project. The church may have been surprisingly resilient, but a catastrophic Bible translation can shake everyone’s use of and reliance on the Bible.

Given these sorts of statistics, Farley argued, individuals could plausibly spend their whole career in software development without ever encountering, never mind running, an unequivocally successful development project.

“I think the vast majority of people in our industry have spent the vast majority of their careers not knowing what a successful software project looks like,” he said.

Farley traced the sorry state of software development practices to a fundamental misreading of the 1970 Winston Royce paper (PDF) considered as a defining the waterfall method that has shaped traditional software development practices.

“This paper was a description of what not to do,” said Farley.

Royce’s paper had gone on to argue for feedback loops and testing, and to “do the job twice if possible”, Farley said.

Royce was “arguing in the 1970s for iterative development” Farley claimed. Instead, Farley continued, we have a situation where taking an entirely ad hoc approach to software arguably leads to more successful outcomes than traditional waterfall approaches.

(from some Luke Partnership materials used in Nigeria)

The waterfall method is to software engineering what the ‘ladder’ of 12-or-however-many steps are to Bible translation; the intuitive idea is that when you conquer one basic step you move onto the next and so in a controlled way move from original idea or specification through to the final product (or translated scriptures). This is an attempt to bring some rigour to what otherwise would be chaotic hacking, and an element of certainty to ensure projects are actually delivered. That is admirable, but unfortunately the results over several decades have been disappointing, because in fact iterating towards an acceptable result is more likely to be successful than always going forward and never looking back.

Small steps, continual evaluation, continual feedback are better for useful software development it turns out, than a guaranteed step-by-step model. I think we in the Bible translation world could do with learning a little from what software engineers have discovered (or run away from).

 Spiral Model translation theory Waterfall Model