[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!
No comments:
Post a Comment