Theolagile Programming

[This post might be better suited for my programming blog: MoterDev, but it is more akin to the thoughts on this blog. I suppose in the future, it will be harder and harder to distinguish between the two.]

Software developers over recent years have been increasingly gravitating toward a development methodology known as “Agile Programming.” This highly collaborative approach to software engineering emphasizes non-traditional strategies such as rapid development cycles (“sprints”), test-driven development, “pair” programming, and cross-functional teams, among  others. The growing popularity of this new trend is testimony to its success in environments where flexibility and robust engineering are valued. I can personally testify to the effectiveness of many of the Agile tenets in my own programming endeavors.

But, while the Agile methods are useful, in my experience I have found that they do not go far enough. I learned years ago that I am a much more effective and productive contributor when I base my efforts on the principles of Scripture. The “life-verse” for my career as a programmer has been 1 Cor 10:31: “So whether you eat or drink or program, or whatever you do, do it all for the glory of God.” (slightly paraphrased). This is echoed in Eph 6:7: “Work with enthusiasm, as though you were working for the Lord rather than for people.” And so, in the spirit of true theologically-grounded productivity, I’d now like to share with you some of strategies that I have embraced in my own career. I like to call this “Theol-agile Programming”.

1. Trust-Driven Development

In a “test-driven” approach, the programmer starts every project by building a suite of (failing) automated tests, then writes code until the tests no longer fail. I prefer to start with a different mindset. I believe that I personally am guaranteed to fail unless and until I seek the power and blessing of God on my work. “Unless the Lord builds the code, those who build it labor in vain” (Ps 127:1a; my paraphrase). Whenever I forget this principle, I invariably wind up stuck and stressed. The magnitude of my own inadequacies quickly overshadows my efforts and leaves me wringing my knuckles in anxiety.

Thankfully I have discovered that there is a much more enjoyable way to code. Trust-driven development asserts that there is One Expert who already knows all about my program. He understands the intricacies of every programming language and every operating system library. He has descended into dll-hell and proclaimed release to the captives. He knows all my bugs and how to fix them, and He simply asks me to trust Him. Trust Him because He is utterly faithful. That doesn’t mean He’ll whisper debugging suggestions from a burning desk shrub, or that He’ll miraculously write my code for me. It simply means that I no longer have to worry about those incessant challenges. I can rest peacefully in any storm with the confidence that He will be faithful to lead me and guide me like a good shepherd to a verdant resting-place. To God, it’s never about the product; it’s always about the process. His goal is to make me a man of faith, no matter how many scrum-iterations it takes. A man who doesn’t cry out to Him, “Lord! Don’t you care if we drown?” but who has learned to enjoy the ride, even when the waves loom large.

2. Prayer-Programming

Now, I must admit, I have never been a strong adherent to the XP “Pair Programming” strategy where coders are encouraged to work side-by-side at the same computer, taking turns with the keyboard. I have participated a few times and I have found that, while it can be fun and effective in certain circumstances, it really requires a well-matched set of partners.

A far more effective tool in my utility-bag is prayer programming. This principal follows directly from the previous one. If I knew that my scrum-master knew exactly how to fix my broken code, and had an open-door policy with all the time in the world, how foolish would I be to stay locked up in my office desperately trying to hammer it out all on my own? But that is exactly what I do all too often. I drift from the TDD described above, and I end up stuck and stressed.

I recently stumbled across Andrew Hare’s blog. He skillfully addresses many of these ideas and more – check it out!

[More to come…]

This I Believe (Essay contribution)

Contributed to NPR's "This I Believe" Essay compilation:

I believe…
that technology can never save us. And I’m sure that most people would nod assent, in tacit agreement. “Of course! Who ever said it could? How silly!” And then they will continue on down the road in their computer equipped cars, with a computer in their pocket and another attached to their hip, speeding to work where, more likely than not, they will stare at some kind of computer or another, for most of the day, only to slip home at the end of the day to watch digital tv served up from a computer storage device, sipping microwave-heated tea.

If you haven’t noticed: the computers have arrived.

I’m sure that everyone would agree that the computer is a pretty clever piece of machinery. A fascinating toy, an indispensable tool – it is indisputably the work of genius. But in all my years of undergrad and graduate studies in computer science, what impressed me the most was all the countless layers of genius that lie below the surface.

We usually see only the top level – the user interface. Those who delve a little into programming begin to see some of the inner workings of the programs, or perhaps get a glimpse of the underlying libraries and drivers. They may even peer into some of the layers of the registry or the operating system. Perhaps they open the black box itself and ponder the mother board or gaze with not a little bit of awe at that metropolitan map carved inexplicably into a fingernail-sized piece of silicon. And deeper it goes, and deeper. Every layer deftly and intricately crafted and intertwined with all that lay beneath it, and each one boasting the extraordinary brilliance and genius of its creators and designers.

For me, uncovering and admiring all of those layers was like looking down through the center of a giant spiral staircase, gazing through floor after floor of a might tower (a library perhaps), and then, beyond ground level, deep into the chasms of a multi-floor basement, and on into the darkened depths into which not even grad students descend. It was an amazing realization for me, to behold the phenomenal depth of the genius of the computer.

So why do I believe that the computer can’t save us? Is it because of some fatal flaw? Some Turing-Church thesis that categorically proves the inherent limits of the machine?

No. What convinced me that the computer can never be our savior, was the realization that all of the mind-boggling brilliance of the computer -- every bit of the genius in its chips – was placed there, just so, by its creators. It was the vast intellect of the designers that bestowed such awe-inspiring complexity to the computer. Giants, on the shoulders of giants, on the shoulders of still more shoulder-riding giants, whose collective intelligence has dared to erect the most daunting structure in history. Energized by dreams more lofty than anything since the architects began drawing up plans for the Tower of Babel, these geniuses are the true masterminds. Even if someday the computers themselves begin to create even more computers, it will always be the brilliance of the original designers that will be on display. Only genius could unleash such genius.

And so, perhaps, at the end of the day, we must ask: is it the giants themselves that will be our saviors? Is it our own genius that will save us?

And as I ponder that question, I am forced to admit that it can not be so. Despite all the weight of the arguments to the contrary, I simply cannot escape the logic that all the genius in our chips – the brilliance in our collective brains – did not spawn itself (the result of some infinite chain of accidents) but was placed there, just so, by its creator. And so with overwhelming awe and wonder I am led to the inescapable conclusion, that the uncharted genius in our race is simply a dim, fingernail-sized reflection of the incomprehensible brilliance of our Designer.

And that is why I believe, that we can never be saved until we finally discover, like the builders of that Babylonian Tower did so long ago, that we simply can’t save ourselves. We need a Savior.