A pattern than I unwittingly did and have noticed in others is that you need to work out what your variation of ‘consultant math’ is for yourself. No matter how many people tell you, you need to blunder through to your own understanding of it. Often by going waaaaay overboard on conferences the first year or so after going independent.

Here is my variation of ‘consultant math’ around whether I will attend your conference or not. Not that anyone will listen to this and not thing ‘hey! I’m different!’ — no, no you are not. But anyways…

The first part of the equation is whether or not I am getting paid to be there. This can either be in term of an honorarium, or flight or hotel (or all three!). Consultant math is pretty easy when this happens … in most situations. But there is the whole problem of Opportunity Cost. Let’s say you are giving me all three of these variables to attend your conference [presumably to speak] but I have to spend a complete day flying there, and a complete day back. That is really 3 days I could be billing people to work on their stuff. If the honorarium only covers 85% of a single day’s worth of billing, well, things start to break down a bit.

Fear not though, the math still might work in your favour if there is a good chance I am going to get new business from attending an interacting with the other attendees. This actually has two parts to it. First, you need to know who your target demographic is. After 3+ years at this, I have a pretty good feel on who I am targeting and the sorts of things they need to hear in order to get them to sign on. (New consultants are unfortunately at a disadvantage and I think this is a large part of the reason why they go to so many conferences in the shotgun approach.) You, as a conference organizer need to convince me that there is a match between my target demo and your audience. (Tip for consultants: check their sponsorship packages, they often include this information in there.) If there is a match, I might eat the Opportunity Cost and turn it into a Marketing Cost.

There is another variation of Consultant Math I have been tinkering with a bit recently, and that is the Sponsorship Option. This is advanced level math and should only be employed once you know your audience since it often requires more risk [in terms of outlay of money]. Upon successful completion of this math you end up sponsoring a target conference [or event association with it]. For instance, the Consultant Math with Sponsorship Option looks quite favourable for Pycon or php[tek], but is pretty abysmal for CAST, Star*, STPCon or even, ironically, Selenium Conf.

I explained Consultant Math to a could non-consultants today [including ish a conference president] which is usually a sign I need to blog about [my variation] it.

So I’m in a pitch contest right now, and easily the biggest outcome is to switch me mentally from ‘talking about my app’ to ‘building my app’. And part of that shift was to got to TorontoGROWtalks last week. Waaaay too much stuff to absorb. (And thank-you startupnorth for the discount code!). Notes are as follows…

Brant Cooper

• took 3 minutes to mention FAKEGRIMLOCK
• Innovation: Disruptive, Sustaining or Rippling?
• hockey stick growth curve is an inverse mullet
• disruptive organizations optimize for learning
• sustaining organizations optimize for execution
• pre product fit, you are pushing the product on the market. after product fit, market pulls the product from you — I’m pushing now, need to stop that, and soon.
• first vp of sales needs to be able to sell without a demo — I don’t look forward to hiring sales.
• figure out your marketing, by going out and sell
• product creates the buzz, marketing is about amplifying your buzz
• you are not ready to market until there are things in the top of your sales funnel
• how do your measure a ‘passionate user’? figure out how to measure satisfaction and then passion
• if you have sharing, measure sharing since its an indicator of passion

Mike Meltzner

• product ownership isn’t an authority, it is a responsibility
• voice decisions the rest of the group has already decided on
• Startup stages: a comparison of 3 models — Marmer stages was mentioned
• job of ceo is to say same 3 things to everyone outside of the company (Speak the vision. Keep the tank full. Build a team). job of product owner is to say same 3 things to everyone inside of the company (important thing this month, thing we’re ignoring, where we are going)
• be in everyone’s business everyday so they know to include you in decisions
• default to no — but help me to help you convince me to say yes
• no — for now…
• who is handling the project — starters, or finishers?
• unsuccessful product ownership involves handoffs

Kate Rutter

• was an updated version of
  
• 
• ux != ui
• ui = delivery mechanism
• ux
  • a mindset
  • experiential payoff
  • inspires the right kinds of ideas
  • guides decisions
• if people are not going to pay for it, you don’t have a business, you have a hobby
• make decisions intentionally
• startup workshops
• if you cant have one user being passionate about it, how do you plan on having 1000s?
• ‘you dont have a product box, you have a product sieve’
• the market will give you permission to succeed
• customers [give you money] vs end experiencers
• cohort watching is useful
• there is nothing better than being schooled by your product
• each stage of the stack has its own ways to test it
• you should be okay looking like an idiot, because this is how you learn

Laura Fitton

• is there any conceivable world where someone would pay for this blob of marketing
• be useful
  • relevant to your user
  • relevant to your product
• start responding to how they make decisions
• its not spammy feeling if it is properly segmented
• HubSpot Academy
• will customer’s thank you for your content?
• hits don’t count; conversions count
• ‘them’ vs your ‘them’
• ‘smarketing’ — combination of sales and marketing

Scott Kveton

• creation stories should all be like urban airship’s
• ‘more of a feature than a product’
• its not lying, its selling forward
• think hard on pricing and packaging
• you really /do/ need to listen to customers
• customers will direct your business far better than you can
• outgrew ec2 within 3 months
• torn down and re-built tech 3 times

Dan Martell

• to have a hockey stick you need to have the flat part
• as soon as you truly understand your core product, get rid of everything else
• you need to instrument /everything/
• know your baselinesactivity streams
  • curious
  • casual
  • core <--- pay attention to these ones
• use in app surveys
• know your funnels
• unless you have core, don’t do this…
  • opn (other people’s networks)
  • shareable moments

Michael Litt

• solve the problem the customer has, not the problem they think they have
• do not trust the data, talk to the customer
• metrics only work /after/ you have product-customer fit
• everything at the start should be outbound
• ever developer should talk to customers

Mark organ

• most important ingredient for founder or investor: conviction
• ‘how does cookie monster mean capital’?!?!?!
• you need to have deeper knowledge about things more than anyone else
• to bootstrap
  • conviction
  • microniche
  • serviceize (charge for anything)
  • high pricing (multiply by 3x – 5x your competitor)
  • systematic scale
• to raise money
  • conviction
  • beautiful story
  • abp (always be pitching)
  • get feedback and connections
  • firm, but coachable
• the best way to get a canadian investor is to get an american investor first
• you do have spend time on planes to raise money

The Call For Participation for CAST 2013 is out and includes

We would like to hear your experiences, stories, thoughts, observations, demonstrations around the lessons that you have learned in Software Testing, as well as how these could influence the way that we approach testing in the future.

And I expect a lot of interesting experience reports from interesting people (it is CAST after all). But how much really, really, new stuff will be added to the craft. I’ll be my normal cynical self and suggest that it is likely not as much as one would hope.

What I would love to see is a CFP that looks something like this.
We would like to hear your experiences, stories, thoughts, observations, demonstrations around the lessons that you have learned outside of Software Testing, as well as how these could influence the way that we approach testing in the future.

My talks a couple years ago all fell into this form. Kids in Armor and Testing Inspiration When You Least Expect It are both examples of what I want to hear people talk about. I want to hear Alan Page discuss how Orchestra composition helps him test better, how Ben Kelly tests better due to years of thwacking people in the head with bamboo, etc.

I also want non-testers to be brought in as the keynotes. Sure, I enjoy listening to James, Michael, Cem, Matt and company, but if you are keynote-ing, you are up against an astronaut in my ranking scheme (Keynote vs. Track). Now I am a baseball fan so opinions are skewed but I think the Garfoose or Shawn Green could also be great. Though they likely cost more since its an actual speaking gig rather than just the prime audience grabbing moment. Or Mary Robinette Kowal about puppetry. Or a Buddhist monk about meditation and breathing. Or. Or. Or.

That there is a speaking circuit where one can recycle topics is a smell I think …

… and another smell is that I essentially wrote this same post back in April including some of the same speaker suggestions; The ‘Un-Testing Conf’. That’s just silly. I should do some work…

Speak Up! is the latest of Jesse Noller’s community-oriented projects. [I'm pretty sure he has cloned himself to do all this stuff.] Having sat in many ‘how to give a talk’ talks (meta!) I’m amazed how often people focus on construction of slides, the narrative and practice (feh!) and forget the most important thing.

BE YOURSELF!

I’ve been saying this for a while, but this paragraph from Cheek was my hero sums thing up well.

Later that season, Cheek would give me the most important piece of advice anyone has in this business – Be Yourself. It’s easy to lose that once you get close to the pinnacle of the profession, to try to change who you are or how you do what you do in order to impress people or to make your way up the ladder that much easier, but Tom told me squarely that there was a reason I was in that booth with them and it was because of what I’d done on the way there. That my success was based on how I went about my work both on the air and off and that any future success would be based on the same thing.

Pulling it back to speaking, people want you and your content not something and someone else when they select you. Don’t change. Even if that means blatantly ignoring cultural norms. For example:

• When I did Set Course for Awesome I was warned that having cussing in the deck could be offensive to the audience. Noted. Did I change it? Not a chance.
• If I am speaking at your event I’m going to wear what I am comfortable wearing that day which is likely to include some sort of snarky tshirt. Looking at some of the photos from Justin Hunter who is over in India at a conference today the audience is in jackets and ties. I don’t think I own a jacket and tying a tie is an exercise in hilarity.

Also, if you put a mic in front of me, you are going to get snark. And opinion. Because that is me. That’s what you get. Anything else would be dishonest. And being dishonest to your audience is not a good way to engage them.

Yes, I think that slides that have fewer words are better in general and that you should tell a story when behind the mic. But if that isn’t you then don’t do it. Be yourself.

One of the traditions in my wacky subset of the testing world is not only building mnemonics, but adding / remixing them. And so, I introduce COP FLUNG A GUN. Which is COP FLUNG GUN plus Automation.

Automation

The primary way to test mobile apps remains to be, literally, by hand. But we’re starting to figure out how to do it though automation. (No thanks to the OS vendors…) As automation frameworks get more mature we should check whether automation hooks are provided by the developers. Unique ids or other identifiers for all interaction bits, synchronization points exposed, etc.

Also included in this is integration into your CI system, since that is the bit that controls the execution and reporting of the automation.

There are certain things that I can say have been with me most of my life. The Dark Tower series is one of them. (The Wheel of Time series, Star Wars, comicbooks have as well. Likely baseball too now that I think about it.)

So last night I’m paying ish attention to twitter while watching the world series and see this flit across my stream.

Wow! Finally finished Stephen King’s Dark Tower series. Those are long books. Enjoyed it, and liked the ending.

— Corey Haines (@coreyhaines) October 28, 2012

Which got me thinking about the whole series. Yes, the whole series. This is the point where my world-builder’s-disease kicks in. See, the Dark Tower is not just the ‘core’ seven books. It is in fact pretty much all his books. If it had a wizard, it is a Dark Tower book. If it had a lost puppy sign, it is a Dark Tower book. If it happened in Derry, it is a Dark Tower book. And yes, The Stand is absolutely a Dark Tower book.

But does the Dark Tower deserve all the praise it gets? I dunno.

For pure scope and intent, absolutely. But that almost feels like it was added after the fact. Or at lease communicated afterwards. Anyone reading King long enough understood his ‘universe’ held Derry near its center, but then suddenly it was part of something else. And his books would have asterisks next to books that were part of the Dark Tower. If it was always his intention to have things part of a larger epic, how come they were not there in the books that came out in the 80s and early 90s?

As for the individual books, on the whole I didn’t really enjoy them. The Gunslinger is a decent read, the next two feel like they are just moving the plot along and the flurry of the last three after his accident feel like a person’s sudden response to facing their mortality and fearing their epic won’t get completed. His inclusion of the accident in the final book seemed heavy handed and too breaking-the-fourth-wall ish. I literally stared at the page in disbelief when that happened. It is an interesting thought experiment to see how it all would have turned out had it not been for that fateful day…

‘Wizard and Glass’ however is an outstanding book and likely my favourite King book (with The Stand (unabridged) being a close second). Its enough of a standalone story that even if you have no want to read the whole series, it is worth a read. ‘The Wind Through the Keyhole’ is much the same tone and feel as ‘Wizard and Glass’ though outside of the main series. Chronologically it takes place before ‘Wizard and Glass’ but is another standalone book.

The more I think about it, the more I feel like the Dark Tower series proper has failed yet the world it has setup has succeeded greatly. ‘Wizard and Glass’ is character backstory set in the world. ‘Keyhole’ is character backstory about the world. ‘Hearts in Atlantis’ is secondary character backstory, etc. Similar to how the Terminator and Star Wars franchises were flushed out through Dark Horse Comics in the 90s, the Dark Tower is being flushed out by Marvel Comics.

What I think I would like to see however is more ancillary stories come out set in the Dark Tower world. Maybe not even by King, kinda like the Star Wars universe. (See The Thrawn Trilogy for instance to see how other can expand a universe while still staying true to it.) But now that Roland has been eight years since Roland reached the top of the tower and ‘Keyhole’ only came out this year gives me great hope that the world will continue to produce things to consume my money.

Other random bits in my head around the Dark Tower…

• ‘The Stand’ is a pretty ambitious book to choose for your first highschool book study
• I read ‘The Drawing of the Three’ (or started at any rate) during a school trip to Stratford to see ‘As You Like It’ and was listening to The Cure’s ‘Mixed Up’ so certain songs are forever associated with the book (such as ‘The Forest’)
• After reading the last page of ‘The Dark Tower’, I immediately went to this page

I’m starting to get back into comicbooks thanks largely to the reboot of the Valiant Universe. I have almost all the original Valiant books in boxes in the basement and I think the reason I was drawn to them was its tight continuity within the universe. Events in one book directly impacted, and did not contradict events in another.

The ‘big’ universes of Marvel and DC have long had issues with continuity due to their sheer size and age. I suspect managing this problem is part of the reason why DC rebooted their universe last year (dumb, dumb move if you ask me…) and Marvel is apparently thinking about it as well. That is not to say that its not possible to have working continuity in a universe that large, and with more than one title per character (Batman has 8 titles right now). My example here is the classic Knightfall crossover (which Batman Returns is loosely based). It was across all the then Batman books and, well, was excellent. And in tone for each of the books. There wasn’t much bleed over into the other books in the universe though… but oh, did Batman bleed.



(What I need right now is a word that means something like hindsight, but for recognizing the choices that might have led the the current now.)

While reading Cem’s The Oracle Problem and the Teaching of Software Testing it dawned on me that in my brain, ‘Continuity’ and ‘Consistency’ are synonyms.

Wiktionary provides a narrative device in episodic fiction where previous and/or future events in a story series are accounted for in present stories as one definition of continuity and Freedom from contradiction for continuity.

So how do I think Valiant did originally, and should now, keep their continuity in tact? Glad you asked! Or didn’t and I’ll say it anyways.

• Keep the number of titles manageable. And my manageable I mean in the area of 16. Now I have no idea the economics of the publishing world are like, but that could give a couple ‘mini worlds’ that could tightly collaborate sacrificing the whole. (Harbinger, Shadowman, X-O, A&A).
• Don’t let the groups of books dictate direction. Where the universe is heading should be a Publisher level decision. The v1 universe had that direction available for anyone to see in big-scope-terms in Rai 0 (best cover of all time)

That’s it. Only two things.

Tying this back to testing/agile, I am starting to notice [now that I am looking for it...] this sort of failings in teams. Teams trying to tackle waaay too much work in a given iteration and when features hit production they don’t work as well as they should have when get into their hands. Happens. All. The. Time. I’ve also seen when agile teams or test groups wag the product dog based on their own whims and biases. Management is supposed to do that. Not you.

(Unless the name card on your desk says ‘publisher’.)

Beyond the Matrix is an excellent article for a number of reasons. Not only does it give a peek to how a major movie came together, but it also gives insight into the difference between writing a book and making a movie.

Here is a paragraph from page 7.

The set was rudimentary: the control room of the satellite-communication center would be completed with computer-generated imagery, imagined by the Wachowskis down to the minutest detail. The scene in the control room, for example, features an “orison,” a kind of super-smart egg-shaped phone capable of producing 3-D projections, which Mitchell had dreamed up for the futuristic chapters. The Wachowskis, however, had to avoid the cumbersome reality of having characters running around with egg-shaped objects in their pockets; it had never crossed Mitchell’s mind that that could be a problem. “Detail in the novel is dead wood. Excessive detail is your enemy,” Mitchell told me, squeezing the imaginary enemy between his thumb and index finger. “In film, if you want to show something, it has to be designed.” The Wachowskis’ solution: the orison is as flat as a wallet and acquires a third dimension only when spun. Mitchell, who had been kept in the loop throughout the process (and has a cameo in the film), was boyishly excited by the filmmakers’ “groping toward exactitude.” “I was like Augustus Gloop in the Wonka factory,” he told me. “I’ve witnessed a long sequence of decisions, which I never had to make while writing a book. Intellectually, I know it’s a replacement, but I don’t feel a loss at all.”

It is this sort of detail that appeal’s to my tester’s mind. And one which I have been noticing since hearing an interview with L. E. Modesitt, Jr. on Writing Excuses (I think it is this episode, but didn’t double check) where he discusses things like the support logistics of great fantasy battles that authors seem to forget [ignore].

And now, you will notice them too.

(You’re welcome)

My son is presently baseball-mad and so went to training day with some Blue Jays last January as part of their Winter Tour. I have no idea how to coach baseball to kids, so I took some notes. They’ve been floating around the basement since then so I’m de-paper-ing them by putting them here.

• Stretches
  • butt kicks
  • side strides
  • long steps
  • frankensteins (high kicks)
  • flamingos (balance on one foot, lean forward)
  • circles with arms
  • fall, then sprint
  • cross legs, then up without using arms then sprint
  • watch the pitcher, then sprint
• Batting
  • Use a tee
• Bunting
  • line up with the front of the box so if the ball drops straight down it doesn’t hit the plate; if it does its a strike
  • pinch the bat
  • rotate feet (into ‘athletic position’)
• Base Running / Paths
  • touch at the front of the bag
  • run straight!
  • lean when crossing the plate to make it seem like you are further ahead than you actually are
  • game: relay where half run from home and half run from second
  • the high-5 at the bag is important
  • when going multiple bags, start running in the shape of a banana halfway to first
  • take two steps from the bag, square them, then two side steps to be in optimal position
• Infield Fielding Drills
  • direct grounder
  • glove side
  • throwing side
  • random side
• Outfield Fielding Drills
  • routes to ball
  • glove positions (above or below hips)

Twitter is excellent for planting troll-bait one-offs, but the blog is better for planting long-tail ones. So this afternoon I tweeted something along the lines of this.

Unless your are interviewing someone for a job that requires [stupid] logic problems, then they don’t have any place in an interview.

And I stand by that. Though a lot of twitter seems to disagree, to one degree or another.

Context. I was at a client today and the two people I am working with came back from an interview…

Them: Do you like logic problems?
Me: Not really.
Them: Want to try the one we just gave in the interview?
Me: Sure…
Them: How long should we give him? 8 seconds? 5?
Me:
Them: Design an algorithm that solves Me: (immediately) Dunno.
Them: Give up?
Me: Nope. I didn’t come up with something immediately and don’t care enough to focus any thought on it
Them: …

This of course led to a much larger conversation about the value using these sorts of things in an interview has. My mentioned above, I don’t think they have any. (Or at least very tiny minuscule amounts to avoid the use of an absolute…).

More context. The interview is for a position that will primarily be webdriver automation using python with some manual testing thrown in there as well (and will be taking over the stuff I put in place.)

So. How does the ability to answer a logic problem help determine the candidate’s ability to do the job? Very. Little. Here is a secret; web automation is not a ‘logic’ problem. It’s not even that hard. It is way easier to be an automator than a tester.

What should you spend the time in an interview for a web automator instead of wasting everyone’s time with the logic problems? Ummmm, how about you have them automate your app. Right there. For real. Projected on the screen.

• What oracles do they establish?
• Which patterns do they use?
• How ‘robust’ are their locators?
• How is their synchronization?
• etc.

These are all critical things to understand about an automator. Especially the one that will take the lead on the project. Notice a distinct lack of explanation why manholes are round or how to determine the odd billiard ball out in a minimum number of steps.

(Oh, and looking up syntax is absolutely ok. It shows they know where to look. We have this internet thing — we don’t need to memorize everything anymore. Now, reliance on an IDE to program for you is not ok.)

I see logic problems in an interview almost as a crutch that the interviewer is using to hide that they don’t really know what they are looking for. And as an interviewee, if a logic puzzle rears its head in an interview the bozo bit gets partially flipped on the whole situation. Do I want to work at an organization that values people who can solve logic problems? Or that are awesome automators and/or testers. (This isn’t to say there isn’t a possible intersection between the two groups, but it is not guaranteed.)

What are a few arguments I have received today in favour of logic puzzles; none of which sway me…

• It shows a high IQ and high IQ is needed for a testing role – People play lawyers on the internet, so I’m going to play neuroscientist. So first, all being good on logic problems means is … you are good at logic problems. A lot of people spend their free time doing these things so they train their brain to spot patterns and build their own solving heuristics for them. Same for crossword-ers or word search-ers. Heck. Look at the whole ‘tester game’ thing. (Of course, the tester game phenomenon has a large degree of arrogance associated with. And no, I won’t play.) Back on topic. No, you also do not need a high IQ to be an excellent tester. Again, I could be conflating IQ with other things (only playing neuroscientist remember…) but there are more firms hiring Autistic people as testers (article).
• It lets us see how they work through a problem(1) – Sure, but is it a class of problem they will experience at the job you are hiring for? Those are the problems you are hiring for.
• It lets us see how they work through a problem(2) – As usual, Michael Bolton provided a Feynman reference (even if it is fictional); Round Manhole Covers, or: If Richard Feynman applied for a job at Microsoft. Its a fun read and on target in capturing what I have seen of Feynman. But he gets a job offer for marketing. Not in test. Not in web automation. His answer would tell me nothing about his ability to do those jobs, though would tell me not to engage him in an argument about manhole covers.

A slight variation on this is of course, FizzBuzz. FizzBuzz is loved online and is somehow seen as the bar that should be met to be called a programmer. I have not once had to use anything FizzBuzz like in automating apps since I started in early 2000. (And that is of course the only experience I can have.) If you are hiring someone whose responsibility includes programming, absolutely you should have them write code. But have it be relevant to the job! As mentioned above, for a web automation job, have them write web automation code! And if you must use FizzBuzz, then you should write a web app that does it and have them automate it.

Way at the beginning I mentioned that the job that originated this discussion is mainly automation and partly testing. The automation side I think I’ve beat to death. Interviewing for testing is, perhaps unsurprisingly, very simple. Have them test! Logic problems will not help you determine if they have a set of heuristics and philosophy for mobile, or payment gateways, or video, or, or, or. Unless your product is vapourware (or super crazy top secret — at which point, have them test something else), have them test your real product! Again, live! And not just silently do it pointing out [possible] bugs but out loud explaining their thoughts. (I wouldn’t have them write bug reports as an interview is a fake scenario and you’re not going to get a ‘real’ bug report.) Flashing back to Feynman, this is the useful part of the article. The thinking and rationality behind the thoughts. As an interviewer, that’s what I care about. Does it clash with mine, does it create overlaps, does it fill capability holes, etc.

But you can’t get that from the creative process solving a logic problem! As a community we claim to care about context, but interviewing outside of context seems like a waste of everyone’s time.