Monday, November 25, 2013

Another BAST Event: Productivity Sucks, How About Being Effective?

First, I want to say thank you to everyone who came out a little over a week ago to help us usher in our first formal talk at the Bay Area Software Testers (BAST) Meetup group. I was officially the first speaker with a prepared talk, and it was a repeat of my talk that I gave in Sweden a couple weeks back about "Balancing ATDD, GUI Automation and Exploratory Testing". Overall, it was a fun time, a great group, lots of great question, and our thanks to SalesForce for letting us use their offices at One Market in San Francisco.

To keep the momentum going, we (that is, BAST) are hosting another Meetup on Wednesday, December 4th, 2013. As part of our mission, we are striving to invite speakers and perspectives that break from the traditional "software testing" talks and focus on additional areas and a broader range of topics. To that end, this month we are pleased to welcome Jim Benson, the author of "Personal Kanban" and a contributing author of "Beyond Agile: Tales of Continuous Improvement".


As seen above, the topic is "Productivity Sucks, How About Being Effective?" Jim will speak to us about the myths surrounding our work and how we think of it when determining what is and is not productive.


Again, our goal is to arrange to have speakers that talk to and about testing, but also to hear from people outside the narrow confines of what we traditionally hear at software testing talks. We think this would be a good talk for anyone, not just software testers, so we are hoping that some programmer, project manager and management types may find this interesting.

Date/Time: December 4th, 2013, from 6:00 p.m. to 8:30 p.m.

Location: The Climate Corporation, 201 3rd Street #1100, San Francisco, CA

The Meetup announcement is here. Please help us spread the word :).

Tuesday, November 19, 2013

Adventures In Failure: Benign Neglect vs Over-Reacting

This is a blog post I hoped I would never have to write. To my tester friends, this has only peripheral relation to my testing career, but it's something I've been dealing with for the past several days, and it's taught me a few things, and reminded me once again of several things I thought I already knew. Normally, I take a somewhat self-deprecating tone with posts like this, but I'm really and seriously bummed about this, so I'm just going to tell it straight without any jokes or color commentary.

Yesterday, my 70 gallon fish tank became a ghost town.

This tank has been up and running, in some way, shape and form, continuously, with one major exception (for a swap-out back in 2007 due to a ruptured seam) for 19 years. In that 19 year period, many fish have come and gone, for a variety of reasons (personal taste and interest, changes in water chemistry moving from soft, acidic San Francisco to hard, alkaline San Bruno, etc.). Generations of fish have been born, grown, given away, and repopulated to other tanks. It was a vibrant community of predominantly cichlids, though it has housed other fish over the years as well. To put it simply, it's run pretty much flawlessly, and without much in the way of tweaking and meddling on my part, for years. That all changed Monday the 11th of November.

Wait, let me step back another few days, to Saturday, November 2, 2013. That day, I did something momentous, and potentially provided the catalyst that started this whole thing. On that day, I made a decision to end a decade long experiment. I'd kept a breeding colony of Convict Cichlids (Archocentrus nigrofasciatus) running in that tank for that time, and it was successful. In fact, it was too successful. I had run out of tanks to house them, and shops willing to take them (even for free; I was flooding the local market with Convicts). With no more room to put them, I decided it was time to make a change. I kept the largest and longest lived males, separated out all of the females and juveniles, and with a final "special delivery" to my favorite fish store, I brought the breeding colony to an end by bringing those females and juveniles to the shop. Yes, we're talking dozens of fish.

In the process, I noticed that they had some new arrivals, in particular several Green Terrors (Aequidens rivulatus). Contrary to popular folklore, the name is a bit of a misnomer. They are cichlids, so yes, when they are in "breeding mode", they can be as aggressive as any other cichlid species, but no more so. As I was looking at them I though "wow, what a great time to balance out the tank with a new species". With Acara (Green Terrors being part of this family of cichlids) and Convicts, as well as my main tank denizen, a Green Severum (Heros efasciatus), coming from similar waterways in Central and South America, I figured they'd be a great addition to my tank. I bought four of them, introduced them into my tank, and then spent the next couple of days getting ready to go to Sweden. Since I was going to be gone for awhile, I figured giving the tank a good thorough cleaning and larger than average water change would be good for all involved, as well as a perfect time to introduce the new fish.

Now we fast forward to Monday evening, November 11th. As I came home from work that day, my younger daughter said "Dad, there's something wrong with Kite!" Kite is the name for the large Green Severum; he's really placid and just drifts around the tank like a big kite, hence the name. I asked what "wrong" meant. She said that his whole body looks like someone poured salt all over him.

Uh Oh!!! I know what that means. We have an "ich" infestation.

Now, I've seen these before, and I've treated them in the past, so I figured, well, this shouldn't be too big a deal. Since I'd needed to get medication anyway, I figured I'd pick it up the next day and start treatment when I got home. For good measure, I'd do another large water change so that I could limit the spread of the problem. Unfortunately, my hospital tank was not set up. Even if it was, I'd need a larger tank to put the Green Severum in; a 6 gallon quarantine tank isn't going to cut it for a 10" fish! Therefore, it meant I'd have to treat the whole tank. Turns out that would have to be the main step anyway, since when I got home, I noticed that the signs of the disease had spread to several of my Convicts as well. With that, I started measuring out the medicine and dosing the entire tank. I also followed the directions and removed all of the carbon and chemical filtration materials from the filters.

Within three days, I saw that almost all of the fish were erupting with the parasites and the tell tale signs on Kite were becoming even worse. He looked like he was coated in a layer of plaster that was cracking away, and his fins were decaying at an alarming rate. With that, I knew it was only a matter of time. Some of the smaller convicts were the first to go on Wednesday, then some of the larger Convicts followed suit. Kite, my oldest and longest lived veteran of my tank, at 12 years, succumbed to the disease on Friday morning. Over the next three days, roughly every twelve hours, another fish would die until finally I was left with only three fish. Looking at the two surviving Green Terrors (two had likewise died during the week), and my longest lived male Convict, I took a look at the two Green Terrors and realized that, if anyone were likely to survive, they had the best chance. With that, I set up the 6 gallon hospital tank, and pulled them out to be monitored and treated. My oldest Convict, I had to leave him in the big tank, and hope for the best. Alas, the end came for him too, last night. As of now, there are no fish of any kind in my main tank. They are all dead.

As of this morning, my two Green Terrors are still holding on, one looking like it might be a hard recovery (he's lost a fair amount of scale over the left side of his head and flank), and the other having what looks like a real fighting chance. My 6 gallon tank is not much, it's definitely not the environs I just pulled them out of, but it will have to be home for the next three weeks, and on the plus side, they are currently still alive. For the first time in 19 years, though, my main tank is now devoid of life, except for what may well be a colony of parasites that I will now wait out the next three weeks, to make sure that they are all dead before I try to start the tank up again.

Many things have been going through my head since this all happened. What did I do wrong? The answers are telling. Most critically, I broke one of my most important rules, and I did it out of impatience. My hospital/quarantine tank wasn't set up. It hadn't needed to be for some time. I was not prepared, and I didn't have the necessary materials in place. Cautious, intelligent me would have set up that tank first, and would have let it cycle for three weeks, then bought new fish, and had them wait in the quarantine tank for three weeks, before introducing them to my main tank. Instead, because of a moment where I was making a major change in the ecology of the tank, I figured "why not?", and I just added them to the tank. What's the worst that could happen? I really hadn't imagined "the worst" would mean "wipe out my entire environment", but yes, that is exactly what happened.

Was it just the introduction of the fish? If that's the case, why were they not sick? Why did none of them show any signs of the disease? Could there have been another potential cause? Yes. Pretty much all fish carry parasites. It comes with the territory. "Ich" is expressed when fish have a stress episode, and those parasites are excited and activated. They then push out of the fish to reproduce and look for new hosts. Could the two large scale water changes in less than two weeks have contributed to that? Well, yes, potentially. The fact is, water pH is probably the one thing, outside of ammonia or nitrite spikes, that will most stress/affect a fish. I try to keep the pH as close to 7 as possible, but when I checked the water late last week, the pH was 7.8 (and yes, that difference is significant). That large a pH swing could have triggered the change.

Could the medication have exacerbated the problem? Entirely possible. One of the dangers of mediating a large tank is that the dosing is very hard to determine. What would be normal for one fish might be too little for another, or way too much for a third. This is why it's best to treat fish individually in a hospital tank if you can. Treating a whole tank can have wildly varying results. It's also possible that the dosing of the tank was too late for Kite, who already showed advanced symptoms.

Could I have done anything different? Sure, and the last option is  the one that really makes me cringe, but I know the truth of it, and didn't heed it. I could have left them alone. I could have resisted the urge to add some new fish to the tank after a major "depopulation". I could have not bothered with the water change before leaving for Sweden. I could have let the disease just run its course. Yes it would have likely killed Kite, but he was 12 years old, already beyond his life expectancy, and having had a really great run. All sorts of coulda', shoulda' woulda's, but no, the thought of doing nothing terrified me. I did what any irrational pet owner would do when their animals are in distress. I tried to fix it with all the tools at my disposal. The net result is a ghost town. Over a dozen valuable fish, but more to the point, fish that were good and dear friends I'd raised for many years.

Why am I mentioning all this? Simple, this is my blog. This is one of my biggest hobbies outside of testing, and one of the ways I observe and learn about the semi-natural world. Often in tanks, there are two things that are killers; overt neglect and over meddling. The middle ground is sometimes referred to as "benign neglect", where we do the bare minimum necessary, and let them sort it out for themselves. I've never been guilty (at least not that I know of) of "overt neglect", but yes, I've frequently been on the "benign neglect" scale. Sometimes, that's just the best way to deal with things, but it makes us feel heartless when we do it. It seems this would have been a time where more "benign neglect" would have been far more beneficial. As it stands, I now have a recovery project underway. I will rebuild, and I will renew this tank. New life will take root here again, but sadly, it will be with a whole new family. All my "best friends"are gone, and they are gone because I over-reacted.

Update: I'm happy to report that both of the Green Terrors seem to be doing OK, even the one that's missing half the scales on the left side of his head. He's being feisty, sparring with the other Green Terror, and thankfully, he's even eating, which means he really does have a fighting chance. I tend to name the fish that stand out in my tanks, and thus, if this little guy pulls through, since it's likely he'll have a bit of scarring that will look like a Pirate's eye patch, I'm going to call this little fighter "Harlock" after Leiji Matsumoto's legendary space pirate. Here's hoping I can make good on that.

A grainy shot of "Harlock" in the hospital/quarantine tank.
I'm pulling for ya', dude!!!

Friday, November 15, 2013

That's Great, But How is This Helping Your Testing?

When I went to Øredev last week, I had a whirlwind of emotions, experiences, learning and changes of perspective. While I enjoyed many of the sessions I attended, and certainly enjoyed giving the two talks that I did, I think it's safe to say that one of the most valuable lessons from this trip happened between sessions I attended, at a table in the lounge area, during a conversation I was having with James Bach.

James and I have had a number of chances to talk in the past, but usually they have been in group settings. I think this may have been the first time that James and I had an extended conversation that was just the two of us. He was commenting on the fact that I had been writing a great deal recently, and that I'd been reading a lot and talking about what I'd been reading in my blog.

During the course of the conversation, we were discussing a number of the books and ideas I'd been writing about, and James homed in on a particular question: "Can you tell me which of these books you have been reading have had a definite impact on your approach to testing, and if so, what is it?" I talked about a variety of books, including my beloved James Burke's "The Day the Universe Changed", and its focus on the interconnected nature of events and discoveries, and how I strive to look for those interconnection points. I gave several examples, and he said "That's great, but how is this helping your testing?" I had to think about it, and I tried explaining the nature of understanding what I know and why I think I know it, and referenced several other books in the process, including "Good Math" by Marc C. Chu-Carroll and how understanding and articulating logic has helped me be more focused and attentive to my assumptions. Again, the same question was asked: "That's great... but how is that helping your testing?"

Through this conversation, I came to a realization... I enjoy reading, writing, and applying ideas to how I test, but I struggle with making clear connections in my own narrative and how I work to actually bring home that point. Sure, I read a lot, and I get ideas, and I can focus on key principles that are interesting, informative, and certainly applicable, but if I cannot readily explain why what I am reading is applicable, or how I am personally applying it, then my effectiveness as a tester is not going to reach its full potential. James emphasized that there are many things that we do as individuals that we struggle to explain. He said he realized he was at a similar point several years ago, and decided that he wanted to make sure he could ground his ideas very clearly, and with unambiguous language, wherever possible. He said he wanted to not just explain what he was doing, or how he was doing it, but why he was doing it. Not just for himself, but so that he could readily articulate it to others and be sure that they understood it.

At the end of the conversation, James handed me a book and asked that I give it a good read and ponder its message. That book is "Rethinking Expertise", by Harry Collins and Robert Evans. It emphasizes a different perspective on how we look at "tacit knowledge", which is knowledge that we have, and skills that we use, but that we have difficulty explaining. James made the point that, as he saw it, I had developed a broad body of tacit knowledge related to testing, and that I was trying to explain it in my writing, but that I had difficulty articulating exactly how I was applying the knowledge I had gained. He suggested that might be something I work on going forward.

I am happy to accept the challenge. My plan is to do exactly that. In future posts, if I am reviewing a book, discussing a technique, or considering a controversy, I will make every effort to try to explain, either in the narrative or in its own side bar, exactly what I feel this topic, book, tool, or skill is bringing to my testing. I'm also willing to bet it will be a much harder challenge than I am currently anticipating it will be. Either way, this fits into my talk and personal philosophy about "not faking it", and I welcome the opportunity to make good on that promise :).

Friday, November 8, 2013

Another Day, Another Live(ish) blog from Øredev 2013

Good morning everyone and welcome to day three of Øredev (yes, I was traveling for the first day of the conference, so you will need to look through #oredev tweets or other people’s blogs to see the first day’s contents). Networking is spotty here. Sometimes it works and sometimes it doesn’t, so I will try to update these details when I can.

One of the first session highlights was to show how Julian Harty has been gathering and purchasing Kindles for schools in Kenya. He has shown how, but using second hand and refurbished materials (3G wifi hotspots, solar panel packs, power cable distributions, etc., and they are distributed to a number of schools, so that gift vouchers, free books, etc. can be distributed to the Kindles, and the ability to change the world is being achieved, one school and one student at a time.

World of Minecraft with Jens Bergensten
The morning keynote started where the conference organizer introduced his 9 year old son, and mentioned how, at his age, he would now be starting to learn English, and during the process of the introduction, it was clear that the boy knew more than a year’s worth of English. Why? Because he had been playing for years the world of Minecraft. With that, it was shown how a generation of kids have learned a significant amount of English through playing and interacting with the game.

Minecraft is a game that has been developed in Stockholm, Sweden, and have about 30 million users worldwide. Though it’s several years old now, they still sell tends of thousands of copies each day.  What is the cultural impact? You can see it in a variety of game magazines, it’s shown up in South Park, and various late night television shows. It’s used as an education tool in about 1300 schools. It’s used to teach geography, geology, history, math, architecture, programming, etc. It’s been said that it may be the only tool to be used in all education levels (primary through university).  This game has become a game changer to go beyond just schools, but also is being used with world development initiatives like blockbyblock.org and UN-Habitat. The idea behind Minecraft is that it is meant to teach children how to create, rather than the typical option of games that focus on blowing things up.


Minecraft was originally developed by Markus ‘Notch’ Persson,  Games like “Infiniminer” were influential on helping to develop the ideas behind Minecraft. From the beginning, Minecraft was created to be simple. It’s a classic “pixel game”, and everything is boxes. It’s like legos for the Internet generation. Example video of the early days of development showed how people have made small projects all the way up to mega objects like a 1:1 model of the Start Trek ship Enterprise. It’s been described as being like Lego with infinite bricks. From simple to complex structures, all is open to the players depending on the resources they gather and implemented. One of the interesting things to see is just how much can be done in Minecraft to simulate construction and building of projects using nothing but a variety of blocks.

---

My talk was next, and this time, I attempted to do a live demo of Socialtext wikiQTests and how we interact with them, use them, and how they fit into my overall talk which is leveraging concepts of ATDD, GUI Automation and Exploratory Testing. I say attempted to because, with me in Sweden, and our test servers being in California, the execution delay was just too great, and it would have resulted in too much dead air. I did, however, do some screen captures and restructured the presentation, so I now have a Prezi presentation that shows the newly revised version. For those who want to see the presentation as it currently stands, go here :).  


---

After my presentation, I sat down with Scott Barber to be interviewed for "Geek Speak", which is a video program for Smartbear. We talked about my being invited to Øredev, and the idea that our messages were being well received and quite popular sessions. I also talked a bit about the BBST courses offered by AST and the SummerQAmp program and what they are about. If we got a good recording, I think it should be posted in the next few weeks, so when it is, I'll let you all know :).

---

I hopped into Anne-Marie Charrett's "Coaching for Testers" talk, which was augmented and made even more fun by the fact that her two subjects (James Bach and Michael Bolton) were both in the session and offering color commentary on the examples and the intended actions and takeaways. I've seen variations of this talk before, but I like to see how she tailors this talk for different audiences. Good fun, and lunch time. I'm hungry, so I'll see you all later :).

---


After lunch, I sat in on Cyrille Martraire’s talk “ Refactor Your Specs”. This talk centered around the idea of the  3 Amigos concept for creating specs and stories. Cyrille broke down the traditional method of writing specs and then changed up and showed where each group has specific skills that are able to contribute. The product owner, Programmer and tester all ned to be represented, and each needs to be active in the process. 


Testers do not, and must not, wait until development is all done with a feature. Specs, for that matter, need not exist at all (gasp!). Wait, what? Active conversation, early and often, can be a big step into being rid of hard and concrete specifications. In organizations that use BDD, the Cucumber/Gherkin statements for your tests can be used as you specification and documentation steps. By treating these as living documents, we are able to keep them up to date, real and rational examples, that can be modified if necessary to be end user documentation or reference-able specifications. 

---

Another benefit to being "out of session"...
seeing Iris Classon walking on a tightrope
(tight belt ;)? ).
I had a chance to sit down with James Bach in between sessions, and what had started as a casual conversation turned into something much deeper, and something I need to do a blog post all by itself for, but suffice it to say James gave me some excellent food for thought towards something I'd been wondering about for a long time, and am getting closer to wrapping proper vocabulary around it.


I missed the sessions during that time, but this brings home the fact that, sometimes, the most valuable interaction and lessons learned may come not inside of a session, but instead between peers and friends chatting at a table in the hallway. This counts as one of those times.

---

Michael Bolton did a sessions specifically focused on Regression testing, or what we think we mean when we talk about or focus on regression. What do we really mean when we talk about regression? Is it that we are afraid of things going backwards? Is it that we are afraid something will break due to our recent changes? Are we afraid of losing face because things seem to break that we have fixed it already? 


One of the interesting things that Michael made a pint about, tangentially, is that test cases are treated as nouns, as things. Testing isn’t an object, it’s a performance, just like notes written on a sheet of paper are not music. It’s music notation. Performing the notes on the page, that performance, is music. So likewise with testing and test cases. test cases is to music notation as testing is to musical performance.


Michael made a point about checking, and that he feels he made a mistake early on in that he cast the discussion of checking vs. testing.  When we are doing fact checking, we are doing a part of testing, but calling it testing leaves out a lot of aspects of testing that  go beyond fact checking: forming hypothesis, observations, questioning, studying, modeling. Those are all aspects of testing that go beyond checking.  

An interesting question... is regression really the biggest risk? Regression Problems are symptoms of the fact that, perhaps, we have a regression friendly environment. Maybe fear of regression is also a symptom. What do the costs of regression structure, and how it affects all of the things we could be doing, might also be worth looking into. More to the point, what tests do we leave on the table when we focus out of proportion energy on regression? It may be a worthwhile trade, but again, maybe we might want to consider what energy we are applying in these cases.

---

We now come down to the final talk of the night, and of the event. Linus Willeij is a long time and core committer to the Linux kernel, so it's a pretty good bet that, if you do anything in the world of computing,  you are running his code. The Fairlight movement was formed out of the West Coast Crackers movement, and was named after the synthesizer used by Jean Michel Jarre. Linus' talk was a restrospective of 25 years of the pirate group and what they accomplished (some may have conflicting opinions as to what that record is, of course).


Linus was more focused on discussing "The Scene" that developed in the early 80's around computers, games, and ways to crack systems and gain access to them. Each community had a computer scene that was, in ways, analogous to music scenes in different communities and countries. In the early days, the scenes were predominantly middle class, white males. It was a self selecting group. There was no organization to join, no management to reign in people, your participation was determined by your participation.

We joke about people being called "elite" hackers today, but once upon a time, you actually had a real way of gating people. Elite hackers were really just those who had access to or owned fast modems. If you had a 28.8K modem in the late 80s/early 90s, you were pretty elite, you had something rare! There were many roles in the scenes, Suppliers, crackers, swappers, spreaders, phreakers, fixers, people who "carded". Additionally there were people who started making their own games and demos.

Why did this group get so big in Sweden? the first reason was that people were bored, and they wanted something to do. There was no game industry in Sweden, so people with interest in making games turned to cracking to fill the need. Linus has provided a retrospective on the techniques used by hackers in the run up from then until today, which has made for a very interesting historical tour.

With that, it's time to bid adieu (or "farväl" to keep in the Svensk ;) ), and I wish to give my thanks to everyone who made it possible for me to be here. To Maria Kedemo for inviting me, to Emily Holweck for making my travel arrangements and helping me to be as prepared for everything as possible, and to old and new friends. Thanks for making my time in Sweden so memorable.

Tack och vi ses snart!

Wednesday, November 6, 2013

Hej från Sverige: Somewhat Live, and sort of awake, at Øredev 2013

Hello everyone, and welcome to another stream of consciousness from your truly. If I seem a little bit more stream of consciousness than usual, please understand, it's 11:30 p.m. on my biological clock. I'm trying to overcome a nine hour time differential. I wasn't feeling it at all yesteday... I'm really feeling it now :).

To start this off, I want to say thanks very much to Maria Kedemo, since she is, first and foremost, the reason I am here in Malmø, Sweden. Maria is the one who extended the invitation for me to speak, so my giddy, bleary and somewhat sleep deprived state of mind is because of her, and I am genuinely grateful :).


Denise Jacobs starts us off with a talk about the Creative Revolution, which for a conference dedicated to The arts, seems to make perfect sense :). She starts by describing a tiny coral polyp and declares that this little piece should well be called "Darwin's Wing Man" since had it not been for this polyp (and we should add quite a few polyp siblings, there would not be a galapagos Islands for darwin to discover and contemplate the Origin of the Species. Denise is one who considers herself a "Creative Evangelist", and the interesting thing is that "creativity" is highly valued in the attributes we consider important in others, but more than that, it is a huge element in transformation. For something we consider so valuable... how can we more effectively use it?  The first thing is that we need to focus on creativity not just for ourselves, but in groups as well. "Creativity is all about making connections and seeing patterns."

Denise makes the point to say that she is talking about a (R)evolution, which should not be confused with "Revolution". With this, we come back to our friend the coral polyp. That polyp is important, but it cannot do it al by itself. It needs others, like itself and with their own genetic structure, to come together to make a coral reef. Sorry I can't give a visual of this, but an entire Swedish audience just did the wave (I kid you not ;) ). Denise used this visual to show that everyone together made this really cool thing happen.


One of the problems that hampers most of us is  that we tend to be too over-aggressive and optimistic with what we want to do. We want to do *BIG* things, but very often, it's a collection of tiny things that get us to the big things. We are even more likely to do something if we make it positive, and even more effective if we make it present (as in present tense). Anchor to a current habit if you want to make a change stick. More to the point, congratulate yourself when you do it, your dopamine receptors will thank you for it ;).


One of the killers of our creativity is that we get talked out of who we are and what we do. We hide our brilliance and our spark because we don't like being nails that stick up (we all know what happens to the nail that sticks up, right? It gets pounded down). When we over emphasize working on our weaknesses, we tend to have very minor improvements i n those areas (and we tend to resent the improvement). If we focus on our strengths, and really leverage them, we can really kick start amazing transformations. If you really want to see this in action, hang around some young kids, as they will be perfect examples of this. Kids don't stress on what they are not good at, they jump into things with what they genuinely love doing. We should do likewise.

We were asked to talk with our chair mates to discuss one of our new topics that we can make talks about. I enjoyed talking with Bjorn Granvik and his ideas about "Joy in Diagrams", which soulds kind of brilliant, to be totally honest. Me? I shared Ministry of Testing stickers with my chair mates and told them about the value and beauty of diverse geographic communities and how we are raising the visibility of software testing. Here's hoping we get a chance to present on those items :).

Creativity is supra-linier; the more we interact, the greater the possibility of creativity. We need to escape our silos, whenever possible, so that we can break out of "sticking with what we know". Ceativity is kick started when we have a broader group and more people to interact with. Getting people together is easy. Doing something with them being together is the harder part. because we tend to tear each other down. Instead, let's try to see if we can "plus" the ideas and opportunities that come our way. There's no guarantee that we will do something awesome with everything, but start where we are, and let's see if we can "let's and" rather than, yeah, but". Oh and for Denise... the plural of "ethos" is "ethe" or "ethea" ;).

---

Next up is Woody Zuill, and the idea behind "No Estimates".  This is tethered in the world of Agile, so Woody said that, if anyone was working in a traditional development environment, there might not be a lot of hope. I know from my own experiences that most estimates are ranging anywhere from ineffective to completely unreasonable. The problem is that we are looking for certainty in places where certainty really doesn't exist.


Time, cost, potential revenue, these areas certainly make sense for us to consider while we look at creating new products and services, but as Woody said, if he was actually good at doing estimates, he wouldn't be making software, he'd be getting rich betting on sporting events (heh, interesting point ;) ).  Estimates are educated (or not) guesses about work we do not understand. Seems that understanding is needed before the estimate, right? How many of the estimates we make turn out to be completely wrong? Do we make bad decisions based on what we think we want, or do we start to get defensive as soon as we make our decisions?


Woody is suggesting we do something un-natural. How about, instead of making estimates, making something that we can quickly put into use and evaluate? How about if we prove value in small chunks, rather than trying to take large pieces of functionality and finding ourselves endlessly surprised at what we end up implementing that doesn't hit the mark? Estimates are used to attempt to predict the future. Add to that "the only sure thing about forecasts is that they are (often) wrong. Unknown multiplied by unknown is... I think you get the point ;). Wouldn't it be great to call Estimates what they really are, which is "WAGs" (Wild Assed Guesses)? If we were to be more vocal about calling them that, we might be able to get some managerial traction on understanding the futility of estimates.


Agile is about discovery and steering. Napoleon Bonaparte was quoted as saying "One jumps into the the fray, then figures out what to do next". It worked for him most of the time, with the exception of that whole Russian Winter thing or Waterloo, but otherwise, he really did have a heck of a run!


"But my customers demand estimates" Really? Do they demand estimates because they want/need them, or because they've been burned too often to believe that we can actually deliver? What if we were to give them a direction, high level, without trying to fake and add minutiae that isn't real world?


 jIf we want to work without estimates, we need to do real work. Focus on delivering quickly, in small batches, and get a gauge as to what it actually is doing. Sounds a lot like Agile, doesn't it ;)?


---
Anne-Marie Charrett is talking about “Curiosity Killed the Cat, but What Kills Curiosity?” and is about a less than stellar consulting gig she took part in. Testing is questioning, and when nwe stop questioning, or when we stop being engaged and providing valid and valuable information, we are in trouble.


Anne-Marie is proud of her role as a coach, and in her view, one of the primary roles of a coach is to be dispensable. She doesn’t want to have to be there forever. She wants to help the teams work better, and then move on from there to work with others. This particular company had three teams, a mix of disciplines, and a handful of dedicated testers for each project. The key focus was to help bolster the testers and improve the testers capabilities.

After talking to the testers, some pictures emerged. The testers felt they were isolated, they had no one to help them, they had excessive points to test, i.e. the hidden work that appears. They were able to make some wins, testers worked together to help solve problems, they did work on cross knowledge, they added coaching to help facilitate exploratory testing, and they revised their automated testing strategy. There was also some wins with regard to quality (what done means, agreement on Quality, checking vs. testing, etc.).

This doesn’t mean everything went well… there was little in the way of stand-ups or communication, Cliques abounded, bugs were not getting fixed, and stories were either under defined or ill defined. Add to that the company owner was s into “Lean startup” that it seemed their trajectory was being changed all the time. Testers were afraid to speak up, afraid to question stories, and afraid to question developers decisions. Anne-Marie said that there was a point she realized that she had made a number of assumptions that, when looked at in hindsight, stood in the way of her being successful. Anne-marie saw that what was the root problem was a loss of curiosity. What kills curiosity?

Being Intimidated
Lack of Understanding
Lack of Authority, Clarity or Trust
Lack of Knowledge or Culture
You can’t kill curiosity if it’s already dead.

Curiosity is a weird thing, it’s hard to spark it when things are making it difficult to be creative and interested. Review your goals regularly and see how the culture of the company might impact your overall strategy.

--


The next section was “Practical Tools for Playing Well With Others” with J.P. Rainsberger.  J.P. stated with a short film about the fact that people are made of meat (the protagonists are aliens observing humans who live on Earth and the way we interact with one another).


In a diagram about debugging a conversation, we start with Intake. In short, what do I see or hear? Conversations go sideways when we are trying to interpret something and they get a different interpretation than what they thought  they heard (or wanted to hear) Meaning follows on.  If we say a statement in English, for some, translating to another language may lose key elements from the original statement. The significance of a message may vary (why do we care about this?). Finally, there is a response, which starts the reverse process again (Intake, Meaning, and Significance). 

If we have an intake problem, we call it a “misinterpretation”, when we have  Meaning Problem, then we have a “misunderstanding”. When we miss the significance, we may have a “misinterpretation” , and then there’s the really difficult area. the path from “misinterpretation” to “response”.  Conditioning, culture, System 1 or Lizard Brain thinking often come into play when we try to mitigate or control significance or response. This was a cool reminder that, often, we think there are culture or personality differences, when in truth, anyone “can have a failure to communicate”. This was an interesting breakdown and reminder about how we get into this situation, that we intercommunicate all the time. Some key takeaways: Think of three ways to interpret what just happened. Ask “what did you intend by that?”, communicate in “E-Prime” to reduce judgment perceptions. Warn the other person when you need to say something uncomfortable.

---

My apologies to the Lightning Talk presenters, but I was running on fumes by the end of J.P.’s talk, and I had to get some quick shut-eye (blessing of the venue being immediately next door to the hotel means I could go and do exactly that).  I have come back now for the afternoon sessions (including my own) and Scott Barber is next up with “Lifecycle Integration of Performance, Simply and Creatively”. Scott starts out with the idea that different users and different roles, performance means different things. Profiling, code design, load testing, production monitoring, etc. all play a hand in these expectations. Load testing, stress testing, etc. are all components of performance. Using a simple math analogy, performance is to load as rectangle is to square. 

The performance lifecycle needs to run from “conception to headstone” as Scott puts it, and likewise puts a spin on the cradle to grave metaphor (meaning it goes further back and further forward). Whenever an idea for an application is conceived, performance needs to be considered. 


An example that Scott discussed was with the Victoria’s Secret fashion show that was live streamed for the first time in the early 2000’s. Research showed some very different profile information than what they anticipated, with a rather large guy audience, and a spike that came later in the broadcast. They did really good research of their target market, but missed the ball when they were talking about the total potential audience. The performance hit was such that they have determined to never be such “Internet Pioneers” again, though the live streaming fashion show does keep going. The healthcare.gov rollout in the U.S. is a current iteration of this. The performance issues with the site is doing more than just being an embarrassment on a technical side, but it’s coloring public opinion for the entire program. 


To prevent poor performance, you have to check regularly and et a feel for performance perspectives as they are developing. We can’t just react when it happens. We have to look for problems first. Ultimately, everyone is responsible for performance, but ultimately, the past has indicated that it is left to the end of the lifecycle way too often. Ideally, it would be baked into every sprint, every story, every iteration. Typically, we look at performance as a sum of Software Performance Engineering + Profiling + Load Testing + Capacity Planning + Application performance Management == Inefficient and Ugly Delivery and Maintenance. Consider the cycle of Target, Test, Trend and Tune. The whole team needs to be invested in the performance of the product. Prevent poor performance with a little work, every day from everyone.

---

James Bach is riffing on testability and what exactly that means. Chuckles abounded when he asked the audience if they were still doing "manual programming", but I think he got the point across. Programmers do have automated programming; it'c called compiling, linking and building. They realized that they were different actions from programming. Hopefully, there will be some dispersion of the idea that manual testing and automated "checking" are different things. Testing, as James puts it, is "learning by experimenting, including study, questioning, modeling, etc.


James talked about the "Risk Gap"; what we know, and what we need to know. Testing helps us close that gap. The larger the gap, the harder it is to test. We don't need to drive with our headlights on during the day (running lights on my car notwithstanding, i.e. I can't turn them off :p ). However, in the dark and the fog, lights are vital. Need a big term for the Risk Gap? James calls it Epistemic Testability.


Testing is all about control and observe. Products have both general and custom components. The general components are tried and tested. The custom (new) components, probably not. There are explicit and implicit requirements. The higher the implicit requirements, the more challenging the testing process will naturally be. Project related testability, Intrinsic testability, Subjective Testability, Value Related Testability and Epistemic testability all ned to be covered to have a chance of effective testing to occur.

James just planted an amazing mental image in my head. As he was talking about so many people who look at software testing as being easy because they use tools such as Selenium and Cucumber. But what about the things you can't test with those tools? Huh, what could that be? That's then James started pantomiming a Disney song, with chimney sweeps and talking, singing mice and a spoonful of testing... go ahead, just let that image run wild in your brain for a minute. You can thank or curse me later ;).

Excellent testing is just like science. Repeat that with me, software testing is *just8 like actual scientific method, with one exception. Scientist only get one build, software testers have to deal with regression. therefore, we have to be able to observe and control as much as possible. In order to test well, we need to be able to control the execution to visit each important state, see everything important and control the variables that might influence it (plug made for the game Sporkle, and yes, I plan to play it later :) ). Logging is huge. If you test and don't analyze log files, you're missing a treasure trove of information that can inform your testing. Use fact checking to back up your creative experimenting.

James used a cool example of a simple random number generator. If we generate lots of runs and plot those runs, and we sort the output, we see that the result is not a straight line. the fact that there is a curve in the line shows that the output over time is not truly random. Some additional issues were shown in the fact that the actual random generator math makes it so that two numbers never appear (999 and 1000). Cool and fun example :).

Next up is... ME :). Tweeters who are here and who attend my session, I'd love it if you can tweet during my session so I can storify them. In any event, I've got to go and get fitted and teched out. Wish me luck :)!!!


More to come... stay tuned :)!!!