An Epistemological View of QA...

In my last post I mentioned that "QA can be seen as an excellent example of a posteriori knowledge" and that it could reinforce arguments against a priori knowledge.

So lets start with the idea of the a priori. Put in very simple terms, this is knowledge you gain before (or prior to) experience. Philosophers like Kant* and Plato believed that there were just certain things you knew -- you didn't have to live through them to know what they were. For Plato, concepts like Love and Justice were gained a priori. 

A posteriori knowledge, on the other hand, is the knowledge that must be experienced in order to be gained; knowledge comes post-experience, so to speak.

And how does any of this relate to quality assurance? Well, QA is a great real-life example of a priori vs. a posteriori knowledge.

Say, for example, you have a specification -- we'll use product spec here, but it can be any number of specifications -- feature, design, whatever. So in your product spec, there is a combination of broad and specific product features -- the things you believe the product should do. You can't detail every single action possible in every feature because you just can't know beforehand that everything will work, or, sometimes, even how.  A product spec is generally written before anything gets built -- it is done a priori, because you have no experience of the actual product itself yet.

As soon as your product is in the build process, you can begin testing. Presumably, you're using a priori knowledge (the spec, in this case) as your basis, but upon closer investigation – or testing – you find that Feature X requires significantly more work (and therefore time and money) than what was planned. Your choice now includes either re-thinking your features/requirements or coming up with a new plan to accommodate for the additional time and budget that's needed.

That's one broad QA example. Another, more specific example would be the way that QA testing itself is done.

Let's say you think you found a bug. Unless that bug is reproducible, i.e., you can invoke that issue consistently each time you perform a particular action, and more importantly, OTHERS can consistently invoke that particular issue each time they perform a specific action – then it can't be considered a bug. Without its being reproducible, you're still in the a priori. You don't actually have (a posteriori) experience of it until you can see that bug and document the steps to get to it. Until then, you really don't Know.

Epistemelogically speaking, and in terms of software testing, we're asking the question: How do you know? 

If we answer in the a priori, we'd say, “Because that's what the spec says.” But once your software begins its testing cycle, you can answer in the a posteriori:  “Because we did x, then y, then z and we got this result.”

QA is a good real-life example of a posteriori knowledge because it is only through testing that we can Know.

---------------------------------------------------------

*Actually, Kant classified knowledge into: a priori, empirical (aka, a posteriori), analytic and synthetic.  It all gets very complicated and confusing, and I admit that I am over-simplifying here for argument's sake.

Time to Start Talking About QA...

QA,  or "quality assurance," has been coming up a lot in my conversations, job-seeking - and naturally, thoughts - lately.  Poor QA! No one wants to do it: companies, as a whole, don't always invest much in it and individuals themselves don't necessarily seek it out as a career path -- at least, that's what it feels like.

At the end of the day, QA just ain't that glamorous.

It can be somewhat philosophical, though, and seems to me worthy of inquiry (yes - inquiry into a type of inquiry). QA can be seen as an excellent example of a posteriori knowledge -- and, by virtue of that, reinforce arguments against a priori knowledge, and can even be used in the case against solipsism.

I'll delve into what it all means in the next couple of posts, so stay tuned.

Tonight is a Three-Kitten/One Old Cat/One Young Dog Night

It has been incredibly busy on my end of the world these days -- yes, being unemployed can mean being productive, just not in an office for a company. Being an unemployed project manager means you're juggling multiple projects, even some with conflicting priorities. In a scrum environment, I'd be my own product owner, scrum master and Team, all rolled into one.

So I've been busy.

Now, to add to it all, friends of mine found a litter of three (most likely) feral, newborn kittens. I knew immediately that they couldn't have been more than 48 hours old. A quick Google search confirmed this, as they still have their umbilical cords. My friends didn't know what to do, except to call me: "She'll know what to do," they said. And, generally, they'd be right.

I've never had the sole care of newborn kittens, however. It's moments like these when I thank the stars there is a such thing as the interweb. I am now a baby kitten feeding, eliminating, disinfecting, nest-making machine.

The tasks themselves are not only time-consuming and physically draining, but is also daunting on some intangible, karmic kind of level. Newborns abandoned by their mothers generally have a high mortality rate: they don't have the benefit of the immune-system-building goodness that mother's milk provides; they may have any number of bacteria or parasites without anyone knowing yet; they may simply fail to thrive...

The responsibility is nearly overwhelming. So I focus on one task at a time (i.e., boil water to clean bottles; warm up the milk, etc.) to keep things in nice, small do-able pieces. It turns out that hand-raising newborn kittens can be an iterative process, too.

How I Learned to Ululate for My Dog

Instead of pointlessly screaming my dog's name throughout a dog park, whilst hiking, etc., I ululate for her.

The story of how this came about is: one day, we were in an urban creek – this means that it's a small creek just off a road in a residential area; the road frequently has cars driving on it. She'd met another dog in this creek and the other dog turned out to be a runner – he was younger and so happened to be in the flight instinct stage of his development. He decided it was time to jump out of the creek and run as fast as lightning (he was a border collie mix) out into the street; my dog followed. I had intended on calling her name, or saying something else that would prove equally ineffective, but my tongue got twisted in a moment of frustration and nervousness and a sort of ululation came out instead. And, as soon as I'd done it, two dogs appeared in sight, happily bounding back to me.

So, despite the fact that it makes me sound like the crazy dog lady (or a relatively old, short, brown, non-breastplate-clad poor man's version of Xena), I now ululate whenever my dog goes out of sight and I want to recall her - and it works. Sometimes it works so well that I get an extra dog or two: bonus.

Resume Writing is Not Fun

I've been working this weekend on re-doing my resume; this not fun.

First, there is the big question I have to ask myself: functional? or chronological?

For the longest time, I'd used a functional format. Then, a couple of years ago, on the advice of a recruiter (who never did find me a job), I changed it to chronological. The thing is about as fun to read as it was to write: first I did this, then I did that, then I did it again..  It pretty much reads like I wrote it for the "And then.." lady at the drive-thru from Dude, Where's My Car?

There are other questions, too, that I'll have to answer for myself before I commit it to resume: what, other than the obvious (i.e., getting a job), is my objective?

Then there are the multitude of formatting questions: bulleted or not bulleted? headers in the left margin, or at the top of each new section? and are those same headers bolded or underlined – or both? Do I use a serif (more traditional) or sans serif (more contemporary?) typeface?

Whatever typeface I use, it'll be one designed by Hermann Zapf, whose work I consider beautiful. I had the great honor of meeting him years ago in a class at my alma mater, where he demonstrated his amazing calligraphy skills for us.

Even with the prospect of selecting a new typeface, resume writing still is not fun.

 

Steve Jobs His Own Doppelganger?

SFGate.com published a gallery of photos of Steve Jobs Over the Years today. I was struck by the contract between an image from 1997..

and one from 1998, about eight months after he was named interim CEO.

Does this look like the same guy to you? He looks like two completely different people to me.

Personally, I prefer his black- mock turtleneck-and-dad-jeans look to the stodgy executive thing.

It just goes to show: sometimes, being a CEO ain't pretty.

A cool job I have never heard of before

I recently met someone who has a cool job I'd never heard of before: he's a Mitigation Specialist. As he explained it, his job is to take detailed life history of a criminal in preparation for a criminal proceeding -- specifically which I didn't remember, so I Googled it. As it turns out, it's for capital cases; mitigation specialists come into play during the penalty phase of a capital trial.

One famous - or infamous - example where the role of mitigation specialist was critical was in the trial of  Zacarias Moussaoui.

The mitigation specialist is an investigator and historian rolled into one: he/she digs deep to uncover all the details, however unpleasant or disturbing, in the person's life that will be presented as mitigating evidence.

Whether or not one agrees with the idea, it's the law in the United States of America:

 

US Code Title 18 / Part II / Chapter 228 / § 3592

§ 3592. Mitigating and aggravating factors to be considered in determining whether a sentence of death is justified

(a) Mitigating Factors.— In determining whether a sentence of death is to be imposed on a defendant, the finder of fact shall consider any mitigating factor [...]*

 

I can only imagine how intense a job this must be, and I thoroughly appreciate the folks who do this for a living (thus my attributing the job as "cool"). But no, I am not contemplating a career change.

 

*brackets mine

Oakland's City Council Is Up To No Good -- YET AGAIN

The Oakland Animal Services shelter is one of the only "no questions asked" shelters in my area -- they take everyone, including owner surrenders.

As someone who's helping a friend re-home a cat, I can tell you that it's incredibly hard -- if not impossible -- to find any place that will take an owner surrender of an animal with a less-than-stellar temperament (uh - not uncommon in cats, by the way).

Because no one will take these unwanted pets is one of the contributing factors to the stray and abused animal population. And this is one of many reasons why having an Oakland Animal Services is critical for all of us -- bipedal and quadrupedal alike.

A friend of mine is a volunteer at OAS and the stories she tells about the work they do is incredible. Ever watch any of the "Animal Cops" shows? Yeah: it's like that, only in real life.

And now they want to outsource (in essence, privatize) the City shelter -- HUH?

For those of you who are locals, please read and write, email, or otherwise speak up about this and help Save Oakland's Shelter.

Agile-ity Training: Dog Training as an Iterative Process (Part Four)

Then the team does it all over again...

So I've now shown how training my dog not to jump meant that I first performed a little bit of requirements gathering and then I had to do a little bit of design, coding and testing along the way:

I did this by initially starting in very small increments of time (given my dog's short attention span) and then  mark and reward in order to encourage even longer stays (increased increments of time). As the stays became longer, I also added other actions, i.e., door knocking, rattling the door knob, etc.. Finally, I tested (or "proofed,") the sit/stay, first by using her favorite person inside the house and then moving the entire process to outdoor areas (dog parks, hiking trails, etc.), ever increasing both time and distance.

As I've mentioned, my dog has about a 98% success rate of not jumping on her favorite people. Actually, this number is probably statistically higher -- we'll say 99%.  Liffey jumping on her favorite folks is entirely random -- I haven't quite figured out what makes her "lose her mind for a minute" and forget her training.

Is it because the favorite people are accompanied by her favorite (dog) friends? Is it because x number of days have passed since we've seen these people? And, since she doesn't do this every time she sees her favorites - be they dog or human - then it's much more difficult to pin down a solution. Is it something I'm doing or not doing that's triggering her jump mechanism?

Thus, the requirement for this second iteration has slightly changed from the first to: no jumping; specifically, no jumping on anyone, ever.  

The difference in this new requirement is that her behavior is sporadic and has no particular pattern that's apparent to me. Or, as a QA tester might put it, "this bug isn't perfectly reproducible."  My response to this is:  but it isn't perfectly irreproducible, either; until we confirm one way or the other, it's still a valid, OPEN defect.

For now, I'll just consider this feature to be still in the re-design phase...

Agile-ity Training: Dog Training as an Iterative Process (Part Three)

Did teaching my dog not to jump take time? Absolutely. The entire process is what I would certainly describe as “iterative,” – and because we're talking about an individual living creature with a will of her own and not an inanimate project, there was backsliding, too. So I had to inspect and adapt regularly as we went along.

For instance, one day she would do her sit/stays perfectly; the next, she would act as if she'd never received a day's training in her life (as if she were raised by.. you know -- wolves). Those were the days when it behooved me to be even more consistent, to reinforce even more positively and to get creative. I would make a game of it by getting her into a sit/stay, hiding somewhere, and then releasing her to come find me: doggie hide-and-seek.

So, from the very humble beginning of a basic “sit;” over time and in small, realistic iterations, happily benefiting from the little bit of value delivered along the way, I now have a dog who does not jump on strangers and who has about a 98% success rate with not jumping on her favorite people.  As for jumping on other dogs, well.. I think I'll let that one slide: the other dogs don't seem to mind, after all.

Agile-ity Training: Dog Training as an Iterative Process (Part Two)

After the one- or two-second sit was well in hand, we extended the time and continued adding more until it was no longer an issue – until Liffey could consistently stay until I released her, however long that may take. As more time is added to her stays, my dog is delivering more value.

And as the training progressed, I was able to inspect and adapt both her ability to sit and stay (until released) and the level of distraction within which she had to maintain those stays. As I've mentioned, we practiced at home and in fun and distracting outdoor spaces.  I also increased the challenge at home by going to the door and knocking on it; sometimes the knocking would be accompanied by door rattling or knob shaking - anything to make the sit/stay process that much harder for a happy, excitable dog.

When she showed that she was ready, I introduced the further challenge of an actual visitor.

Now, I'm sure that my dog would tell us, if she could, that one of the toughest challenges she had to face in her young life was to keep her rear end on the floor in the presence of her favorite person in the world: her dog walker. But she did do it. Again, at first it was for a mere few seconds; over time she was able to hold her stay until released.*

*Of course, I should also say that this required the cooperation of our amazingly patient dog walker (we miss you, Tami!): she would essentially ignore my dog until released and free to say hello – and then she would physically lower herself to greet my pup, so that keeping "four on the floor" was much more feasible.

Agile-ity Training: Dog Training as an Iterative Process (Part One)

Recently, after spending a few hours with me and my dog Liffey, a friend asked me how long after I got her did I begin training her?

"Immediately," was my answer. He was surprised that I didn't wait for her to reach some developmental milestone before I began teaching her. I explained to him that he may have been thinking about old-school, traditional (aversive) training techniques, which generally recommend waiting until a puppy is four months old before beginning training.

But thanks to the work and research of animal ethologists, behaviorists, trainers and veterinarians from the last several decades, we know now that puppies are perfectly capable of learning simple behaviors like "sit," very early in their lives. Some service dogs, interestingly, begin their learning as early as six weeks old; a good, reputable breeder begins imprinting puppies even earlier than this.

[My pup came to me at 8.5 weeks knowing the sit,down, leave it and take it, which the fine folks at the East Bay SPCA had taught her and which we use to this very day.]

The fact is, that dog training is an iterative process; as such, the experts suggest we begin training our pups immediately, rather than wait for a select milestone in the project schedule.. er, I mean, a select milestone in their development.

What do I mean, exactly, by "iterative?" You'll recall that I previously quoted The Elements of Scrum:

“a little bit of requirements gathering, a little bit of design, coding and testing, and delivers a little bit of value..”  and then you do it again.

We can certainly think of dog training in the same way.

Let's take jumping, for example. On a regular, consistent basis, I am jumped on by every kind of dog, from 90-pound American field Labs to 5-pound chihuahuas and everything in between. I have been jumped on by every age of dog, as well, including adult and senior dogs who should have been trained otherwise but were not. Let me say to those dog folks right now: it ain't cute. I don't like having to wear synthetic clothing (aka, my “crazy dog lady clothes”) every day because you don't and/or won't properly, positively train your dog to stop jumping on me, a stranger.

But, thanks to those remiss dog people, I have now gathered a requirement – I will teach my dog that jumping on humans is unacceptable behavior. But how?

Well, to start, I didn't teach my dog to "stop jumping;" rather, I taught her to sit, stay and then "say hello nicely."

In reality it was even more iterative than that; I got value in very small amounts: first, the “sit” had to be solid – whether we were at home, at the dog park, along a hiking trail, on the sidewalk in a busy shopping area, etc. Any place that is distracting/fun for a dog is always a good place to practice or “proof” the good behavior(s) you want.

Once the sit was firmly established, we moved on to our “stay” – first, inside the house. Initially, my wriggly dog could only do it for a second or two; she could only deliver a very little bit of value (I took it, happily).

To be continued...

 

Agile-ity Training: Dog Training as an Iterative Process? (Introduction)

Most of the development environments I've been around or exposed to have been more traditional than Agile and have therefore followed more traditional methods like Waterfall. There are other places to learn more about the history and theories of waterfall and other methodologies. I'm here to relate my own experience with these methods. (One day, I may tell you the story about the time I was involved in a project that had no method whatsoever -- a project manager worth her salt would call this "crazy-making").

For now, I can tell you that, in real life, developing software under traditional models mean that you plan, plan, plan/document, document, document: you write statements of work, marketing requirements, design documents, functional specifications, product specifications, database design requirements (if applicable); and if you're planning to actually test your product, then you'll need a test plan and a set of use cases at a very minimum. These are just the basics -- your company will likely have its own further internal documentation that it requires. In any case, it's all very linear. Technically, it's supposed to be sequential; in my experience, however, a good percentage of the planning and documenting happens concurrently.

So you plan, plan, plan/document, document, document and develop and test and expect - and hope - that it all goes accordingly and that the product you end up with is exactly what the marketing, engineering, quality assurance, management and client teams all envisioned it to be. Or not. Usually, realistically, not. The end product is typically some generally acceptable estimation of all that planning and documenting: you take what you got and then move on.

At the end of the day, what has happened is that the hundreds of man-hours put in by many people across multiple teams that went into all that planning is now moot -- and you've wasted, amongst other things, the most precious resource along the way: time. (Of course, finance team members will look their P&Ls and tell you that what they lost was money or possibly "opportunity costs," etc.; since I'm a project manager and not a money person, I'm going to say it's time).

And this is where Agile methodologies come in and ask,

Rather than pouring your heart and soul into a plan that you know will change, why not jump in, do the work and assess and change along the way? Wouldn't an "inspect and adapt" approach make more sense?

Yes; yes it would.

The fact of the matter is, "a software project is too complex and chaotic to be managed via defined processes;"* yet software development has been and continues to be done in this way: we keep trying to hammer a square peg into a round hole.

In the recently-released Elements of Scrum, authors Sims and Johnson explain that, in agile development, one doesn't complete a particular step before moving onto the next:

"an agile team [..] does a little bit of requirements gathering, a little bit of design, coding and testing, and delivers a little bit of value to the customer. Then the team does it all over again..."

When compared to the traditional way of doing things I've described above, Agile, too, sounds like crazy-making. For software development, Agile represents not just a paradigm shift, but a fundamental incommensurability of Kuhnian proportion.

Okay, so: traditional methods are planning-intensive and agile methods are not. You with me so far? Good. But where does the dog training fit in, you ask? In much the same way, traditional (aversive) dog training is about planning, too: you set a dog up to “misbehave” and then you punish her, hoping that, after a few times, she'll stop doing the thing you've set her up to do. Traditional training methods may or may not work – we could argue the point all day, no doubt. But the old way of teaching your dog is in stark contrast to positive-reinforcement training, which is much more an iterative process: when it comes to dogs, you gotta "inspect and adapt" as you go along.

In the coming days, I'll discuss just how Agile methodologies line up with my real-life experience with positive dog training; both methods have much more in common than you'd think.

* Sims, Chris and Hillary Louise Johnson. The Elements of Scrum. Foster City: Dymaxicon, 2011.  p. 68.

Cognitive Dissonance: A Start

In the last few months, I've found it challenging remembering normal, once- everyday words, terms and phrases. The example I'll give here is "cognitive dissonance," since, ironically, I experienced cognitive dissonance about forgetting "cognitive dissonance." 

I vaguely recall now that I'd originally learned about cognitive dissonance via Sterne's Tristram Shandy -- something about a hot chestnut in someone's trousers.

That I mention any of this at all should indicate to you that I have some free time on my hands, which is true.

One of the biggest downsides of unemployment (and there are many) is that a good portion of the knowledge you've accrued begins to dissipate: it seems to drift off into the vapor. Whether or not you'll gain any of it back is a matter of pure speculation and, sometimes, fear.

I've recently realized another problem - one that's apparently inherent in being unemployed and having a dog.  Spending a great deal of time hiking with and training a dog is a positive and rewarding thing to do; as the saying goes, a tired dog is a good dog. But there is a point at which using one- or two-word commands for a good portion of your day begins to inform the way you communicate with fellow human beings. A matter-of-fact and slightly firm, "Drop it" when a dog has a dead mole in her mouth is perfectly appropriate, whereas using that same tone to say, greet someone you like? Not so much. Or, though telling a dog "left, now" when a bike is coming down the hiking trail is okay (and preferable for the health and safety of all), demanding that someone "move, now" is most certainly not okay. Nor am I proposing that it should be:  we humans need a more robust way than sternly uttering a word or two to convey our ideas, thoughts, emotions, experiences, etc. -- and a complete sentence is still the best way I know of doing so.

So, in order to stave off further adventures into cognitive dissonance and just plain old-fashioned memory loss, I will post here occasionally about various topics, from Scrum to dog training, with a bit of literature and other miscellany peppered in (i.e., I've been thinking a lot lately about dog training as an iterative process..). Stay tuned.

*Please note that all dogs mentioned in this post were duly rewarded with yummy treats for their "drop its" and "lefts."