Adam Goucher

Killing the Buddha

adam — Mon, 13 Jul 2009 13:26:18 +0000

As much as I would love to be able to spit out random tidbits of Buddhist wisdom on command, I can’t. But when I was reading Chris’ Kanban Kerfuffle, this one bubbled to the surface.

If you meet the Buddha on the road, kill him!

As usual, there are many, many explanations of what it means, but the one that I like best is from the Daily Buddha.

Whatever your conception is of the Buddha, it’s WRONG! Now kill that image and keep practicing. and I don’t think it means you cannot achieve Enlightenment, but it does mean that you really cannot conceive what it is until you get there. stand out in the discussion.

Now swap our ‘Process’ or ‘Best Practice’ for Buddha.

The software world is afflicted with the Shiny Object Syndrome. RUP, CMMi, Agile, XP, Scrum, Lean, Kanban, etc., etc., etc.. And it seems like the half-life of each object is decreasing.

Am I an Agilista? I don’t think so, though I do advocate agility. Which is partly why I get a kick out of the ‘we must do this process‘ zealotry. What is the Best Practice or Process for your organization? No one knows except you. And it likely isn’t going to look like someone else’s. Instead, companies should pick and choose from all the processes available and come up with something that works for them, their people and their products.

Have I done Kanban before? No. Do I like the idea of non-defined iterations resulting in a constant stream of value being released? Absolutely. But I think I like it even better using TDD / pairing (XP) and daily stand-ups (Scrum).

I think too that part of the value and experienced QA person brings is to know as many of these processes as possible and when (and which parts) to kill, and which to embrace.

Lessons from the bullpen

adam — Fri, 10 Jul 2009 02:09:22 +0000

The Blue Jays released (fired) one of their pitchers yesterday. While discussing it on the radio yesterday, Jeff Blair said the following.

In baseball the bullpen is their own little island. They’re removed from the team while the game goes on. There are a lot of personalities and issues that can go on. Everyone has roles and responsibilities and every successful bullpen needs what amounts to a sheriff or a marshall. To kinda keep track of guys; to tap them on the shoulder and say ‘you better start to loosen up’ based on how the game was going.

That’s an interesting dynamic that I hadn’t thought about before. I suspect the same also applies to product development.

A major league baseball team typically has two major components; baseball operations and everything else. In software, we have the development team (which I include coders, testers and even support in that mix) and everything else (marketing, hr, sales, etc.). Let’s look a little smaller. Your product / feature / release team (self-organized or otherwise) is your own version of a bullpen. You sit together (physically or virtually), you all have roles and responsibilities and you likely have someone who is the ‘lead’.

I put that in quotes because it could have many meanings. It could be be that they have been officially designated as the lead. But it could also that they have assumed the mantle just by their actions.

The ‘tapping of shoulders’ I think is a big part of being in a lead role. Part of what is expected of people in lead roles is to bring their experiences into the mix. “We should do X, because I have seen Y and Z before.”

I’m not sure I like the usage of ’sheriff’ or ‘marshall’ in this context, but I don’t really like the term ’scrum master’ either.

Culture change catalyst

adam — Fri, 10 Jul 2009 02:08:36 +0000

I seem to recall a definition of Culture from an Organizational Behaviour course as being the reflection of a group’s values and beliefs. I could be slightly off on the verbiage, but that feels right (and serves my purposes now). So what is a company’s culture? It is a reflection of the company’s values and beliefs. Not of the individuals that comprise the company, but the organization as a whole. Yes, the individuals have an effect on it, but that effect is heavily skewed towards upper management or other people of influence.

A change in culture is the result of some sort of catalyst. It could be that the CTO was replaces with someone all gung-ho to SOA. Suddenly it is all-services all the times.! More services than you can share a stick at in fact.

The catalyst can be more subtle than that too though. If one developer becomes test-infected than maybe they both create better code and they tell two people, and they tell two people. Its the network effect at its more utilized.

Since it is July it is time for the Tour de France. And with it comes the perennial articles on doping. Cycling peddles a cleaner image showed up in today’s paper. While discussions of the cat-and-mouse games that go on are fascinating, these two paragraphs really stood out.

On of the most encouraging signs is that some riders are starting to volunteer tops to drug testers about rivals they suspect are still cheating, breaking the code of silence that long prevailed in cycling, says an official directly involved with testing at this year’s Tour, which will roll into Paris on July 26.

Because of the necessary secrecy around drug testing, the official spoke on condition of anonymity. He believes the lesser-paid riders can no longer afford doping programs that are sophisticated enough to evade the password regime and so are spilling the beans on those they suspect still can.

Something changed, and so the culture changed as a result. What part(s) of your culture could use a bit of gentle nudging to change for the better? And are you able to do it or is something else still necessary?

Your team is about to shrink

adam — Thu, 09 Jul 2009 12:52:58 +0000

In case you haven’t noticed yet, the economy sucks right now. And with economic suckage comes layoffs. Of course, in this industry layoffs can, and do, come at all points of the economic cycle. If you have been doing this awhile, you start to develop a sixth sense about when things might be coming.

This is even more important as a team lead as it is your responsibility to make sure there there are not (big) knowledge gaps on your team. Things like how the build is tooled, or to how to configure the automated tests and technical details of a feature can absolutely kill a test team’s velocity.

According to this article there is a much larger problem looming ahead. And that is that the job market recovers.

Huh? How is that a problems? Well, here are some choice quotes:

Fifty-four percent of employed Americans plan to look for a new job once the economy rebounds
Of those ages 18-29, 71% say they are likely to look for new jobs once the economy turns around
“I can’t wait for the job market to improve,”

Take a look at your team. How many people are there because they really want to be there, or are they there because the market conditions prevent them from leaving?

Walking the walk

adam — Thu, 09 Jul 2009 02:20:57 +0000

Having a ‘bug free’ product is not enough to guarantee success. In very few markets is there truly only one product which could be used. More often there are a number of smaller options even if the market is dominated by a few players. In this situation, the event that happens before someone downloads, installs and more importantly pays for your software is a convincing that this is the right product for them.

Being ‘bug free’ is certainly part of that convincing process, but there are factors external it as well. Your reputation in the marketplace, your reputation to them, cost, comparability to your competition and support policies all quickly pop into mind.

But there is even another layer deeper than that, and it deals with the optics of how you conduct yourself and your business. Here is a list I’ve been mulling for awhile.

Selling a [security] product but being one of your competitions larger installations
Talk a lot about making buildings more energy efficient and choose an office with ancient, single-pane windows
Don’t eat meat because it is ‘cruel’ but wear leather shoes / belt
Providing organic fruit flown in fresh from around the world during sales meeting for a carbon reduction application
Not dogfooding your application (whenever possible)

I think the connecting thing through all these is that ‘walk the walk’. If I was in a position to sign a contract for a product or service, I would be looking at these things as part of the decision process.

Think about how you, or your company, fares this sort of scrutiny. Then log bugs against where it falls short.

Pitchers and Roughnecks

adam — Wed, 08 Jul 2009 12:54:27 +0000

Pretty much every person in North America knows who a pitcher is, but much fewer know what a roughneck is. A roughneck, at least in oil terms is someone who works on the drill rig floor doing the hardest and dirtiest work. So what do these two very opposite job types have in common and how do they relate to testing? Well, nothing really other than I have a quote about both.

Here is where he becomes a pitcher rather than just a thrower

I heard this one last week late in a game where I think the game was tied and the pitcher had managed to load the bases. For a pitcher, this is just about the most stressful situation they can get themselves into. Especially when you factor in no outs.

In testing we have all sorts of stressful situations, but as your career progresses, the number of them where you have to be a tester rather than just someone who bangs on the keyboard. The question is, are you ready?

The problem is that we are seeing more city kids and less farmboys

I was watching The Rig on the weekend and in this particular episode the crew was staying in town and one of them got too drunk to go into work the next day. In reaction to his firing, one of the more senior members of the crew pointed out that with the oil boom they are seeing more people who grew up in the city and not from a farming community. They implication being that people who grew up on a farm understand hard work and have a better work ethic in general.

Testing is (usually) not a physically grueling job. It can be very mentally tough though. Could your approach and attitude towards testing more that of the kid who got up at dawn to throw hay for hours or that of someone who grew up coddled in a suburban enclave and drove to the corner store.

How to be a Community Superhero

adam — Mon, 06 Jul 2009 22:21:18 +0000

Sheeri Cabral did a talk at a recent MySQL Conf called How to be a MySQL Community Superhero. While the context certainly was in terms of MySQL, what she has to say applies to any community.

Need to be more Batman than Superman
Write
- blogs
- articles
- howtos
- tutorials
Teach whatever you know how to do
Start / organize a user group
Offer to record other people’s presentations to help spread knowledge
Most importantly, listen to what community members are doing and what they need. Help foster connections between the two groups.
Even if your solution wasn’t the best, if it was good for you, it is likely good enough for someone else too. Spread it.
Don’t be afraid to make mistakes
Don’t do it for the fame and glory. Do it because you want to.
It takes time and effort

A Conversation with Stuart Halloway

adam — Mon, 06 Jul 2009 22:18:41 +0000

I spent a bit of time yesterday afternoon out on the deck watching Corey Haines’ interview with Stuart Halloway. Well, in between telling the puppy to stay out of the garden, that Remy’s toys were not his, etc., etc.. Halfway through part one I realized I should be taking notes and so restarted. And here they are.

Agile’s first principle is getting the right people together and getting out of their way
Interview process – rotate through team doing pair programming with each for a day
To professionalize as an industry, practitioners need to know what they know and know what they don’t know. And not sell stuff in the latter category.
Is what you are doing ‘hygiene’ or ‘triage’? Triage is pick a couple goals and ignore the rest. Hygiene is the bare minimum acceptable standards. Without hygiene, the patient gets sick and dies. (Re automated tests and code bases)
Caring about what you do and how you do is part of being professional.
Avoid islands of self-delusion
Code is the instantiation of some part of a business process
Code is never done. Its organic
Enable success rather than prevent failure
Remember, you are the expert. There is a difference between getting advice on how to fly the spaceship and giving over the controls.
More than half of the cost of software projects is discovery
When velocity changes, it is usually an indication that something ‘new’ has happened or something is not captured in the process
The point of velocity is predicability
Anything we do, we do because we did something stupid and it hurt
The whole industry needs to be going to functional programming.
The best idioms are not yet known. There is still a lot to be discovered.
B corporations
A benefit of pairing: everyone on the team knows the strengths and weaknesses of everyone else on the team
‘Hacker in Residence’ – 6 week-ish visitor to team to inject freshness and new perspectives
Small Agile companies should form networks of similarly companies with same philosophies

Selenium and Canvas

adam — Sun, 05 Jul 2009 17:42:01 +0000

I don’t need this yet, but will eventually so here are three different blips of information I’ve collected over the last month about using Selenium with the next generation of web applications. Or at least ones that use the Canvas tag. Crazy enough, they each involve Jason Huggins (who wrote Selenium originally); its like an interview, minus the whole interview part.

The first is a talk by at the May meeting of JS.Chi called The Future of Web App Testing and How to Stop It

As yourself how would blind users use your application? If you have made your application accessible, it has been made testable.
Canvas solutions will look amazingly like flash ones
Everything thing that someone can do to your canvas tag, expose it as a method in js
This generation of tool do typing and clicking. Next generation ones will have to do actions the way the application does

Up next is a log from irc (#selenium on the freenet) involving Jason and myself.

[2:58pm] hugs: did i see you say a couple weeks ago that you were trying to get selenium working with html5 canvas? did you ever solve it?
[2:59pm] hi, adamgoucher… the moral of my story is that canvas-based apps are untestable by default… unless devs put in work to make them testable
[3:00pm] have any ideas on how to make them testable? am potentially going down the canvas route on something
[3:01pm] so it was mostly a soapbox rant/speech to JS devs saying “think about testing!”… Because the DOM is no longer available (for free) inside the canvas tag, apps that live 100% inside the canvas tag will no longer be “accidentally” testable/recordable by tools like Selenium IDE
[3:01pm] ah. I (generally) don’t care about IDE
[3:02pm] it’s not IDE per se… it’s the lack of the DOM inside of the canvas tag… that makes it an opaque black box
[3:03pm] kinda like Flash, Silverlight, or Java applets…. from the point of view of a DOM-based testing approach that Selenium relies on
[3:03pm] ah. care about that aspect
[3:04pm] the *solution* to testing a canvas-based app, which is very, very similar to how to test a Flash or Java Applet from Selenium… is to write and expose a JavaScript API to manipulate anything/everything of interest that is working/living inside that canvas tag
[3:04pm] Selenium can then call methods on that API… and world order is thus restored

And lastly is another irc log with Jason about using flash and selenium together, but equally applies to html5.

[11:16am] flash, java applets, silverlight, and all browser plugins (quicktime, etc)… are opaque black boxes to Selenium IDE…. because Selenium is implemented in JavaScript…
[11:18am] the author of your specific flash application would need to code an actionscript<->javascript bridge to expose internal methods to javascript in the browser… *then* selenium could do things to the flash object… but *recording* those actions would still take more work
[11:19am] other ‘competitors’ to Selenium IDE (like iMacros or Chickenfoot)… “cheat” by using native system libraries to click inside flash objects…. but because the opacity of those flash widgets, they’re still flying blind and can only really send clicks to absolute screen x,y coordinates and *hope* that they landed on the right button
[11:20am] but, hey, at least that’s better what IDE can do! (So we hope to steal that feature someday!)

The moral of all these? If your developers are going to be using html and specifically the canvas tag, it is imperative that you work with them to get the testing hooks you need. And the earlier in the process the better.

Agents of Change / When you’ve lost the room

adam — Fri, 03 Jul 2009 00:40:03 +0000

Two ideas smooshed into one in this post.

The first is the kinda myth that Testers (QA folk) are Agents of Change within an organization. We have the power to mould the product or service into our belief structure. And this is true some of the time, and sometimes very untrue. And this isn’t necessarily bad.

The true phase begins immediately after after joining a group. You are the outsider. Once you are an insider, people have bias and opinions about you which colour their opinions of your ideas. This cross-reference is deadly to your change agency roll. How much success have you had leading a change in a different direction on a team where you are established? (And do not have organizational clout to lead the charge as Testers rarely have it.)

I remember hearing a podcast from David Linthicum where he mentioned a survey or something which showed most successful SOA projects where proceeded by a change in the CTO/CIO. The implication was that the previous holder of the title had lost the audience’s attention. No doubt they will be replaced by the next great architectural wave.

How long this period lasts is a bit of a mystery. (Gee, thanks Adam.) Sometimes it ends with an obvious bang, but other times it is subtle. If you miss the change, then you might succeed in change, but it likely will be through happenstance rather your actions. So what are some signs? Here are some that I have witnessed recently (and not necessarily directly about me)

Sighs during meetings when you start to speak
Your follies are discussed on length
Emails get routed to the blackhole (faster)

Can you get back your Agent of Change title once it has fizzled? I suspect so, but I suspect it might need to come with organizational clout. And once you have that clout you need to work twice as hard to maintain it as your agency half-life has decreased significantly.

One final thing.

Being an Agent of Change is fun and certainly rewarding as there is often a bug finding multiplier for fixing a busted process. But providing quality-related information to stakeholders can also be fun and rewarding too. The trick is for you, and your management, to understand which role you are supposed to be playing, which you are playing and if there is a divergence of the two.