Permission to Prosper - On Testing and Christ
bourbon java testing agile church christ
Tonight I went to church for the first time in a few weeks, and as I ran out the door I grabbed my new Moleskinne notebook so I could take some notes and hopefully not drift off to sleep again like last time[1].
People often talk about 'really getting something' out of the sermon, and it's been a long time since anything really hit me with any direct relevance, but tonight's sermon by Paul de Jong titled "Permission to Prosper" really struck a chord with me - not on any spiritual level, but on an agile development and testing level. Confused? Read on.
It was not the presence of God that formed me, but his absence which broke me.
-- Mark Derricutt
Even before the sermon started the above thought started to hit me, growing up I was born into the church, but it was never really forced on me. In this way - God has always been apart of my life, he's always there in one shape or another - quietly waiting till I call on him, and it's usually only when I turn away that his presence (or lack there-of) is really felt.
With software development, unit tests (and the testing frameworks behind them) are (or should be) always there, running quietly in the background waiting to come to our aide when the need arises (oops, bad commit!). However, if we turn out backs on our tests, remove them from the build process, we start to feel their absence as bug reports and deployment issues start to trickle in.
Sometimes you might have never had tests in your code, and you're unaware of the unconditional love regular test suites offer. They don't lay blame, they don't criticize, they may slap you around with the cold hard truth - but they do so in love :)
Paul made several points during the sermon, which I'll paraphrase, and translate into something more test-related:
Develop the ability to listen
One of the first steps in increasing your agility is learning to listen to your code, and more importantly - to listen to your tests. For the most part they shouldn't be saying much, just going about their business making happy noises. If you've not yet got any tests in your code - listen to silence, listen to the echoes around the gaping void, listen to the impending pain.
Your code should be purring like a sleeping kitty, or growling like a hungry rabid dog. It should not be silent thou.
Complacency embraces a limitation called satisfaction.
If you find yourself with silent code and you're not actively testing your code, you'll be lulled into a false sense of code stability, this endangers the life of your project. It's bad.. mmmkay.
Realize your value to God (and your code, and your team)
As a developer, you are important to your team, and your projects success.
John 10:10-14
The thief does not come except to steal, and to kill, and to destroy. I have come that they may have life, and that they may have it more abundantly.
I am the good shepherd. The good shepherd gives His life for the sheep.
But a hireling, he who is not the shepherd, one who does not own the sheep, sees the wolf coming and leaves the sheep and flees; and the wolf catches the sheep and scatters them.
The hireling flees because he is a hireling and does not care about the sheep.
I am the good shepherd; and I know My sheep, and am known by My own.
You have come that your code may have life, and life more abundantly. Don't be complacent in the code you write, substandard code begets substandard applications; but with sufficient testing the health of the code and overall project increases, and with it so does your own value to the team/project.
The sheep need you.
Believe its your mandate
Matthew 28:19
Go therefore and make disciples of all the nations, baptizing them in the name of the Father and of the Son and of the Holy Spirit
As test infected developers it's our calling to introduce unit testing to as many projects and development teams as possible. To worship and wash the feet of Kent Beck should be every agile developers twisted (and hopefully private) fetish.
Make the next level normal
Expectation opens doors held closed by limitation -- Paul De Jong
By making regular testing the 'normal' mode of development, the lack of testing becomes an aberration, a scar on the project that should be removed as ones earliest convenience.
For the sake of your fellow developers - don't let your code become a leper to be cast out of the city walls. It's just not pretty, and people will laugh at you.
There were several other points made during the sermon but this is where things started to leave my analogies to developer testing so I think this is also a good place to end this posting.
Disclaimer: Since returning from church this evening I've been drinking cheap Bourbon and Cola, the proceeding post may end up as the ludicrous ramblings of a religious nut case, but it may also turn out to contain some useful prose on developer testing.
Comments (3)
I think you give too much importance to "developer testing" as compared to the original source material you work from. But despite side jokes about Kent Beck, maybe we can have a chance to appreciate the original material anyway. So thanks.
Hrm .. why do I feel a Revelations quotation coming on?
Yes, okay, here it comes! "19:20 The beast was taken, and with him the false prophet who worked the signs in his sight, with which he deceived those who had received the mark of the beast and those who worshiped his image. These two were thrown alive into the lake of fire that burns with sulfur." Translates to - we finally made our RPC two-phase commit work and all of that bad data in the second Oracle instance has been backed up and stored on the Windows NT box no one touches, whirring in the corner.
I'm not much intersted in the title of this website, but it might worth to have a look at it: http://www.evilbible.com/