Unit test shepards

I read with interest over the weekend this unit testing and TDD blog post from Douglas Hubler. I met him in real life a few weeks up in Chicago at the annual ClueCon, and was very impressed

I tracked down his email address and started to write a private email, but then as I re-read my draft and his piece, I noticed that it was a 'talking draft' by him. As such, I decided to surface my thoughts here

---

Hi -- Russ herrold (ex CentOS) here -- we met at cluecon

You put your finger on the problem well here:

"Project Maintainers" were always in fear of holding the bag on contributions that introduced bugs while not advancing their employer's goals

which is the well known 'capture by the employer problem' in FOSS. I am not saying (and would never suggest) that employer sponsorship of an interested 'Project Maintainer' is undesirable -- just the opposite, as it funds getting SOME motion in some cases (i.e., when it suits the employer's goals, or is not a clear 'CLM' -- career limiting move). Of course this path leads to 'freeze ups' similar to what we see in Debian Stable, where nothing short of dynamite (or a working remote exploit) seems to work to pry some forward progress into the main trunk

I put on my 'agile' thinking cap, to scope out the implications of your post

To work, the "Unit Test Sheppards" need to have global mandate to commit at least unit tests, via a Version Control System, and there needs to be a working Continuous Integration server. If this 'breaks the build' either the test is wrong, or the code is wrong. In the first response to 'breaking the build' the CI server has to revert the test, and file an exception report, to be owned by the UTS in the first instance, with a CC to the PM

This gets a 'heads up' in front of the PM, and a careful UTS will at a minimum either: 1) acknowledge that the test was ill-considered, withdraw it, and close the bug; 2) amend their code to correct misunderstanding that resulted in a broken test and re-attempt the commit [closing the bug, with the possibility of a 're-entry' of a new bug on the revised test], or 3) add documentation to the bug filing that indicates why the test is right [perhaps something as simple as pointing to a release target milestone, or part of the Requirements document] in preparation to handing the bug off to the PM (staying on the bug as a CC), and handing it along to the PM's queue

One problem is that when there is only a single PM, there is also only a single point of blockage, and 'real life' intervening, or a work-plan to do a substantial refactoring (perhaps even already partially working in a private tree), or even a non-public agenda on the part of one's employer may prevent the PM from ** wanting ** to respond 'just now' if a well-form test and bugreport gets dropped on them ...

... but if the unit test is 'right', usually it is proper to add to a test suite. I put to one side whether one should run all unit tests every pass; Tests do rot and one may well need to trim obsolete tests away, or refactor old ones to match code reorganizations; clearly one answer when the suite gets 'too big' is to start prioritizing, adding stochastic selection to generally omit tests related to rarely encountered failure modes and so forth

But a well written test never fully 'goes away' by default. At some predictable interval, of course, the 'full boat' of ALL tests, as well as more rigorous end to end functional tests are needed. Beck's TDD book glosses over this to some extent as his focus was development, but 'testing' means much more than 'unit testing'

One additional avenue toward a solution would be to convert the single PM 'person' into a trellised PM 'role' or 'team' containing two or more non-affiliated project members

By and large, FOSS works better when there is a consensus approach to management of a resource. It is basic group dynamics that achieving consensus is easier in a small team, able to consult in the 'stand up five minute meeting, and to come to a tactical 'what is the simplest thing that we can do' to conform to a well-formed test, write (or adopt) the unit test, apply it, and move on ;) With only two people in the PM trellis, or a senior and a junior relationship, the group dynamics may result in impasse, which is only visible to the 'outsider' UTS as 'nothing is happening on this bug'

Lots of inter-person political approaches exist here, but ultimately and in most projects, there is a agreed-to Release Manager team with global commits, that has to be willing and able to 'take up the reins', intervene to intentionally 'break the build' in HEAD when an impasse continues 'too long' [I assume here a model of a stable release, and a developmental HEAD], and force the PM to respond (perhaps by relinquishing participation as a co-PM)

I don't have an obvious candidate solution to suggest here, as there as many approaches are possible, and I've seen the issue as a project lead, as well as a mere participant, and sometimes simply as a concerned onlooker

Caller ID, wiretapping, call recording, and the federal Do Not Call list

There is a witches brew of rules that people making outbound telephone calls need to thread through. Also, the recipient of a call needs to observe some as well. Let's start in reverse order:

Particularly, in the US, some states require consent from only ONE party to a telephone communication; others require TWO [or ALL, in the case of a conference call] participants to so consent. The asserted misconduct case of Linda Tripp in Maryland comes to mind. Linda got into some hot water for chatting up Monica's lovelife with some girltalk about Bill Clinton and recording it without needed consents from "that woman, Ms. Lewinsky" and then turning those recordings over to Kenneth Starr's office

Neither side of the aisle is without stain in this space, it seems; recall that back earlier in the Clinton administration that a couple in Florida recorded a conference call bridge leg, on which the cell phone conversation of Representative John Boehner (R-Ohio), was connected. They later pled out to a criminal charge concerning this. That call (said to have been intercepted within the state of Florida through a common radio scanner) also included then-Speaker of the House Newt Gingrich and other House Republican leadership folks. The tape turned up, inter alia, into the possession of Representative James McDermott (D-Wash.), who then flipped the tape to The New York Times and the Atlanta Journal-Constitution. This drew a lawsuit from Boehner against McDermott, seeking to impose to civil liability for violation of the federal [anti-]wiretap law, alleging that no effective consent existed

Stock brokers commonly record ALL calls, and I assume have paperwork in place at account opening time, that effectively and irrevocably obtain consent to such monitoring and recordation, and as I think it through, must contain some sort of representation and warranty by the customer that all parties connected from their side of the call brought in have also consented. Clearly, sometimes this turns out NOT to be the case, and yet I do not recall seeing any litigation as to improper recording of a conference bridge. Curious

And then there is the federal Do Not Call list -- seemingly a shield for the consumer to ward off unwanted solicitation calls from unknown third parties. All the phone numbers under my control have been registered with the enforcing agency, the FTC, and should be showing up on the database tapes for telephone solicitors to elide. This does not happen of course -- sadly, anonymous VOIP calls, false and forged Caller ID information, and simple omission of caller ID data prevails; the ways to dodge the requirement are well know to telemarketers, it seems

But I have been working in the caller ID adjunct industry -- if you need real time screen pop information of inbound callers, I have been a rep for TelComp -- for longer than I care to remember. Be sure to mention that Russ sent you if you call Larry directly, or contact me for a system design and suggested implementation

I was on the phone with Larry earlier today. We have provided the web and email presence since the start. The domain registration says 1995, but I know we did a trade show in LA before that with a web presence up. I was doing a bit of debugging on SMTP AUTH issues with him. Commonly we will leave an open line when we do this, and I listened to him field calls for an hour or so. Larry is endlessly patient on support calls, and I hope to be as patient when I am doing support. ;)

The call had discussed industry trends and practices, and in part the topics of this blog post were fresh in my mind, for we 'talked shop' during running down his email issue

The next call, not two minutes later, went like this:

Phone rings, and the caller ID has no name information, is from a number not known in a lookup to my real time 'whitelist' database, and is from out of the local area code --- a potential outbound solicitation call

Me: Good afternoon. May I help you?

Other party identifies himself as calling from "Merchant Services" and asks for 'the decision maker' at my business.

Me: That's me, all right; we have a practice and policy of recording all calls for quality and training purposes. May I have your consent to such recording, please?

Other party: (confused) uhh -- OK, I guess

Me: Great, and thank you. How may I help you?

Other party: Well, I am calling about your merchant services account. I was calling to make sure you were getting the best rate ...

Me: (interrupting) Sure -- thanks. What is your firm's name and address please?

Other party: ummm

Me: (interrupting) ... you see, I need that because this is a residential number that is on the Do Not Call list, and I need that information to send the lawsuit papers to ...

Other party: (click)

Much more satisfying that simply silently hanging up at my end. Feel free to "clip and save" this handy outline. A copy to crib from at each phone just may come in handy