We are NOT drumming up people to collect wood! (Pre-Presentation)

Feb 20, 2012 at 5:31 PM
Edited Feb 20, 2012 at 7:48 PM

Dear Purdue Students:

On Tuesday November 29, 2011, I attended day one of a three-day object-oriented design class taught at Intel by Bob Koss, one of the contributors to the book Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin (Uncle Bob), founder of Object Mentor in Gurnee, Illinois. If I remember correctly (I often don't), it was on day two of the class that Mr. Koss took some time to talk about and demonstrate what to me was a fascinating new way of developing software.

Bob showed us how easy and fun it can be to write some code to test other code that hasn't been written yet. Of course any program that tests something that doesn't exist must fail by definition; otherwise, it doesn’t deserve to be called a test. The adrenaline rush kicks in when you write just enough code to make the test pass. I’ve heard rumors of people who create entire software applications by repeating this process over and over again!

I’m a bit of a risk taker. And I’ve never been one to blindly follow tradition. So I was eager to take this alluring paradigm shift for a test drive of my own. I’m sure my friend, Kevin Pirkl, remembers how around 5 PM I burst into his office and insisted that he come bear witness to my first successful failing test case that passed only after I created the software it was designed to test. Whether this new development drug was any good for me didn’t matter. I was hooked. My brain was awash in endorphins and needed more.

By Friday December 2, 2011 I had written my first testing framework that I felt was worth sharing with others for the purpose of receiving feedback and constructive criticism (viz. showing off). Bob’s response was, “What are you trying to show here? Why aren’t you using NUnit (my preference) or MSUnit?” My response to Bob’s first question was “An incremental improvement in my unit testing/design skills.” And to the latter, “Lack of experience.” If only I had known then what I know now about what Kent Beck, the x-man himself, said in Test-Driven Development: By Example regarding “rolling your own.”

Fast forward a few days: On Monday January 9, 2011 I received a message from my friend and teacher at Purdue University, Dr. Aditya P. Mathur, author of very exciting books including Introduction to Microprocessors and Foundations of Software Testing. Aditya told me about a couple of students that were registered with him this spring in an independent study class on Software Testing. He asked if I would be able to recommend a term project for them to work on. He also cautioned me that we would only have four weeks to spend on the project—Week 4 of February through Week 1 of April with a 1-week spring break in March.

One problem led to an opportunity led to a problem led to an opportunity, etc. And here we now stand, cradling the infant OpenHopla in our arms, with the sun rising before us in the East.

Onward we press to the next problem/opportunity…

If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

–Antoine de Saint-Exupery

The paradox is:

  • What specific tasks and deliverables shall we specify for said students to sink their teeth into over the course of the next few weeks?
  •  And how do we specify said tasks and deliverables in the wake of the wisdom of Antoine de Saint-Exupery’s words?

I assert a good place to start is with my best beloved friend, Integrative Thinking:

According to an article about said friend on Wikipedia:

Integrative thinking is a discipline and methodology for solving complex or wicked problems. That theory was originated by Roger Martin, Dean of the Rotman School of Management, at The University of Toronto and collaboratively developed with his colleague Mihnea C. Moldoveanu, Director of the Desautels Centre for Integrative Thinking.

The Rotman School of Management defines integrative thinking as:

"...the ability to constructively face the tensions of opposing models, and instead of choosing one at the expense of the other, generating a creative resolution of the tension in the form of a new model that contains elements of the individual models, but is superior to each."

The website continues:

"Integrative thinkers build models rather than choose between them. Their models include consideration of numerous variables — customers, employees, competitors, capabilities, cost structures, industry evolution, and regulatory environment — not just a subset of the above. Their models capture the complicated, multi-faceted and multidirectional causal relationships between the key variables in any problem. Integrative thinkers consider the problem as a whole, rather than breaking it down and farming out the parts. Finally, they creatively resolve tensions without making costly trade-offs, turning challenges into opportunities."


There you have it. Problem solved, opportunity had! Right? Humm…

Enough philosophy talk. On to business. We’ve got a schedule to keep, damn-it!

But before we cut, let’s measure twice, this time with the help of another one of my fine friends, Smart Choices: A Practical Guide to Making Better Life Decisions, by John S. Hammond, Ralph L. Keeney, and Howard Raiffa.

In a nutshell (which reminds me of another awesome friend of mine: C# 4.0 in a Nutshell by the Albahari brothers) Smart Choices recommends that we take the following approach to choosing our “tasks and deliverables” smartly:

NOW we’re all set! We’ve got Integrative Thinking reassuring us we can have our cake and eat it too. And we’ve got Smart Choices spelling out the process in 5 or 6 or 7 or 8 easy-to-follow steps. What more can we ask for?

Of course, this is supposed to be a discussion. And right now I’m simply blowing hot air into the Aethernet. But we have to start somewhere. So here goes:

My problem, as I see it, is two-fold:

  1. I want to be a good sponsor of Dr. Mathur’s software testing course, and in the process reflect positively on my employer, Intel Corporation.
  2. And I want to see my newborn baby, OpenHopla, get off on the right foot in life and grow up to be a happy, confident, successful open-source project.

And over the course of the next few weeks, my objectives are:

  1. To provide students with opportunities to practice and learn about the Tao of Testing.
  2. To develop OpenHopla to the point where she can be published.

So what are our alternatives?

I contend that this is a good place for a break in the discussion, because a) this “discussion” has gotten awfully long-winded, not to mention one-sided, and b) it’s 10:20 AM and said students and I are scheduled to have a real discussion in about 40 minutes. So…

To said students: Your (our) first task is to review this message (which presumable you are doing now and are almost done doing!) and the presentation materials I’ve made available at http://openhopla.codeplex.com. ASAP, respond to this discussion thread with:

  1. Your problem statement.
  2. Your objectives.
  3. A list of alternatives, suggestions, and/or questions you have regarding tasks and deliverables that you might like to pursue based on your problem statement and your objectives coupled with my problem statement and my objectives listed above.

Whew! Are we there yet?

John Spurgeon
Hillsboro, OR

Feb 24, 2012 at 3:36 PM

I composed the message that began this discussion in Microsoft Word, if I recall correctly (I often don't). Then I copied and pasted the message into the CodePlex editor. A feature of this operation is that some of the text that has been copied may not be pasted (or may not be visible) if the text is formatted a certain way in the source document (e.g. if the text is part of a list of one sort or another). I discovered and reacted to some instances of this feature earlier. Only today after re-reading my message did I discover another one. What amuses me nearly as much as the feature itself is the lack of comment about the text now in question that was affected by said feature. If a bug exists in a feature but no one uses the feature, does it make any noise? Apparently not. And I'm now making the sound of one hand clapping.


P.S. Sincerely apologies to my friends Mr. Hammond, Mr. Keeney, and Mr. Raiffa. Perhaps I should offer a reward for your mysterious advice that has gone AWOL.