Participating Hour of Code - a one person view

I've been thinking and preparing for quite some time, but some weeks back I got together the final details to take action. I went to http://code.org to be reminded that Hour of Code week is December 8.-14 which also serves as a nice start for the Smart Creatives Club I've been volunteering to run with my son's school as soon as we get all practicalities sorted.

Smart Creatives was a term I picked up from a presentation by Eric Schmidt at time I was trying hard to explain why I dislike the concept of "code school" that misses out a core of what makes me love work in technology.  The following picture is from the presentation.

Instead of growing programmers of the likes I meet mostly, I'd like to see my kids grow up knowing technology and programming, but putting that together with understanding of purpose (business) and creativity, and choose a corner / combination they will love the most. I really love testing, and find that out of these three, my focus is more on creativity and business expertise, but technical knowledge is there as well.

I've also grown really fond of this list that went around in twitter a while back. I don't want to teach kids to write code, I want them to learn ways of collaborating to create solutions they would find useful. I want to emphasize collaboration. 

Emphasizing collaboration makes Agile Finland ry a perfect home for the things I'm setting up. I'm really happy to be able to announce that my favorite non-profit is there for participating the code.org code week by having an open free Hour of Code for 30 kids on December 8th 18.00 - 19.30 at Leppävaara Library. And that Agile Finland is equally supportive of the private Hour of Codes I will do with two groups at kindergarten Viskuri (5-yo & pre-schooler groups) and group of 1st graders in Malmin peruskoulu. The one at Malmin peruskoulu will then continue as a monthly club, not about programming per se, but about creating together, in collaboration. So far I've decided we're going to be working on multi-media book created fully by the kids for the spring 2015, meeting once a month.

Last week I had the pleasure of meeting a 15-year old girl, who as far as I understood, did not consider computers as something she would be particularly interested in. Spending a week testing with us and being actually very very useful with the courage to speak out, I hear she is saying that testing might be fun. I've agreed to hire her for some of the work I would need done for my side business, and will invite her to join me to co-teach (being paid) the Hour of Code. She might not end up with the love of technology and testing I have, but I think this might also be infectious. Pushing code first isn't the way to keep me engaged, perhaps that could be true for others, like her, as well.  She's super smart, and it would be a loss if she missed out on the best job there is in the world - creating with computers.

I've just published a call for action for others to join for the Hour of Code in Finland, I would be happy to help out locally. There's a huge need for volunteers to show the ropes to the young ones, and I'd love to see us agree that code is just one tool yet a very powerful one.

Empowering developers to do great code

Good conversations are powerful. I made a new friend over organising Tampere Goes Agile last weekend. As he seemed curious about me presenting - something I don't get to do when I organise - he found a video of my talk in Latvia two years ago and watched that. Having watched, he pointed out that I said something horrible. At a point of the conversation I'm having with the audience, I refer to how things are at my current, back then new, place of work. I talk of large amounts of bugs and the number of people testing, and the idea that with a lot of bugs, there's a lot of fixing so adding testers might not be a smart or necessary move. And I say that developers don't care for fixing bugs.

I found that observation particularly interesting, since the answers I tend to give come out of context I work in. Back then, I was struggling with a new team that released once a month but were lost on all kinds of testing. Releasing once a month was "agile" to them. The work was very heavily lead content-wise by a product manager, who would tell the developers which bugs they could fix. The product manager would easily decide on refactoring as well, the team was very much powerless. The fact that the bugs got listed as feedback was new, and there was not an actionable mechanism of fixing that many issues all at once. It wasn't due to regression that the product was broken, it just was that way and the end users (or the product managers) wouldn't come back with that feedback unless they really had to.

Talking about that point with my friend made me realise that the world that empowered agilists live in is quite different from this one. You get a lot of say on how whatever you're implementing gets implemented and you work on making code beautiful, not getting instructions not to refactor from the product owner. You stand your ground on including what is important to include when doing the work, like (unit) tests. Refactoring is continuous, and there's not a need to go ask for a "six month project" to take time to clear the mess you've gradually created.

With my reaction of explaining more of the context I was in then, I realised two things. First of all, I realised we've gone a long way in the two years I've spent with them even though we still have a long way to go. Second, I realised I was using context at hand as an excuse for me to focus on things in my direct power. There are plenty of ways I could have focused more on empowering the developers. I could have just focused on helping them through the braveness to refactor, focusing on development skill instead of what I was into, the study of my own testing skills in whatever context I was handed.

What may be horrible for some can turn into normal for others, and my developer colleagues had been in that world of normal for such a long time that they had given up to an extent to the perceived lack of power in saying how they do things. They were lacking feedback through testing. At first when they started getting the feedback they had been asking for as I joined in, it really depressed them. The amounts of issues, the lack of time to handle any of those, that doesn't exactly turn out motivating. Dictating what was to be done from outside the team wasn't motivating. And with the lost motivation, the driving force was the perceived lack of power.

The core of my answer from two years ago still holds. I find no sense in hiring more testers, when the needed focus on a team is clearly on the side of fixing. But the idea of developers not caring to fix the bugs is an unfair statement. When pushed not to think for a long time and give in on the level of quality you would want to deliver, you may appear not to care. But often that is just a way of coping.

I know my developer colleagues a lot better now. I know they care. I know they can do things. I've had people over training them on unit testing (and refactoring while at it) and coding in general - things they did not get to do enough. And they've found their inner strength to feel empowered to do things better through teamwork and new technologies that boost their motivation as certain things (performance related) are now in the realm of possibilities.

The same team that I commented on two years ago as developers who don't care now work in smaller chunks, reacting to recent feedback instead of having to fix a pile of problems that had been left back from the lack of feedback they always requested.

I just love the power of good conversations, that leave you thinking to a point of writing a blog post in the middle of the night. This conversation in particular is a good one, the core reminder for me is that the positive thinking on what my developer colleagues do turns into a positive change over time. I should be careful implying that people who have not found the power to use their smarts would be intentionally that. Empowerment and encouragement are game-changers for the better. Timely feedback supports that. And there's more I can do to help them, faster.

Two things that bother me on #stop29119 discussions

Let me start with my stance on #stop29119 - I have signed and I think everyone in any way impacted by testing in software should sign it - customer/product organizations trying to succeed on software business in particular.

But still, in all the discussions there's two points that bother me and a lot of the critique revolves around.

• 'Standard' the word and its definition
• Available options for the contents of the standard

'Standard' the word and its definition

A few days back, I saw Lisa Crispin tweet a reply to Michael Bolton that I'm strongly paraphrasing from my memory. The reply was related to a discussion on agile testing as per Lisa's new book and pointed out that not everyone appreciates time spend on word games as they have a full-time testing job to attend to. It caught my attention, as it was pointing out a problem I feel I'm having with context-driven testing arguments, and a problem that is in the core of discussions for #stop29119.

Many people suggest strongly that there should be no standard. Standard the word strongly implies a connection with the regulations, and through that, compliance and lawsuits of non-compliance. I get that. I agree that standard is a very risky word to use if we mean 'guideline'. But I think I hear the other side on this as well.

I live in Finland and Scandinavia is quite different from USA. Really. The whole discussion about standards isn't that big of a monster in the world I live in. It becomes a monster occasionally with EU regulations and it's always been a monster with things regulated from USA. But in the little fluffy cloud I get to live in, it just doesn't matter that much. I'm sure its not equally bad to everyone in USA either. But in this particular fight for #stop29119 the definition of that word becomes a key issue.

Standard the word has many contexts. After all, we're talking of context-driven testing with testing area not having set meanings on the terminology. Words are communication between people, and for testing terminology we don't believe in set terminology but trying to understand and hear out what the other party is saying. How come the word standard is that different from all the other words we use? How come we can't accept that standard in one context is regulation and standard in another context is guideline.

The fact that this guideline ISO 29119 is totally worthless contents that make things worse is a different story. But the basic idea of attacking the word standard seems like word play I don't even care to win. The risk of compliance requirements is relevant for certain contexts.

Available options for the contents of the standard

The other point that bothers me is how many of the opponents seem to handle the critique of not being constructive as in offering real alternatives. From the friendly, yet disagreeing local discussions I've had, I've caught a strong feeling for the organisations driving these standards, there's a real need of a box they label ISO 29119 but that the contents of that box could be something other as well. It might be that I'm optimistic, but I don't like the answer we tend to give on what to put in the box: nothing. We don't do standards. We don't believe in them. I don't believe in them. But I can respect that the idea that drives my local colleagues towards a standard is a true belief in helping out the ignorant in getting good testing. That box needs contents.

I have a personal suggestion as to what to put in that box. I want to put Rapid Software Testing in that box. But to do that, we'd have to get past the idea of the word 'standard'. 

I have an option for the content of the standard. So, the ball is again on the standards organisation: if context-driven (or rapid) testing is no different from the current contents, how about changing it radically. 

Testing starting from that base of values and ideas would be much more relevant that the paper-piling approach the current contents drive towards. It would be helpful to take things forward for the world of agile and still remain relevant with the more traditional mechanisms. We can't say the same about the current contents.

Win-Win?

To get anywhere from here, we need to start making compromises. Compromises to how strongly we feel about the word standards, compromises on how serious we are about no standard-like documentation about testing can exist. The standardisation organisations need to win too, it's not exactly fair to say we want them to stop doing the business they are in. Or is this really something that can, by no means me resolved?

Disclaimer: I'm tired of being attacked for the choices of words or my opinions. This post is very much my opinion, and I'm not going to stress over my choice of words for other than my good intent. I'm happy to engage in discussion that aims at mutual exploration of what (and why) I think that changes my mind. But please, picking on semantics of words without the intent of communication - let someone else do that.   And reminding me on the fact that I'm not a native speaker is somewhat insulting. I just don't care for the exact words, I care for discussion and understanding of agreement or disagreement - communication. 

Seeking for conflicting evidence: agile & testers

One of the things that draws me to context-driven testing is the idea of scientific methods, and seeking for viewpoints that might even be opposing in search of better understanding. For me it's become clearer that whatever I believe in are beliefs, and while I'm prepared to strongly argue in favor of them, there's other people who would look at my beliefs and conclude that I must be wrong. The more of these disagreements I run into, the more I appreciate the idea of mutual respect: there are arguments where winner cannot be announced. But we can still get along, it's not personal.

Agile, testers and testing must be one of these disagreements. All in all, I personally think agile is the best thing that has happened to testing, with the emphasis on feedback (testing) and the cycles that make acting on that feedback possible to extent that wasn't there before.

There's also the downside to agile, which seems to be the constant need to defend the idea of being a tester.

Whatever you are doing in a software team and you help adding value to the product it means that you are a software developer. Period.
— Adrian Bolboaca (@adibolb) October 10, 2014

I'm a tester, I'm not a developer. I try hard being a developer and I feel miserable most of the time. I am a tester and loving every moment of it. Personally for me, it's a matter of staying in software industry. And I believe software is better off having people like me. It's how I feel, and regardless of how much you explain, you can't change that. The employers might change that, not giving me jobs unless I'm a developer. Perhaps that's the core of the argument - which belief system the employers will choose. All I can ask is to respect how I feel and not impose titles that my head refuses to accept without forcing as "no other options" - a very negative way.

It appears James Bach feels something in the same direction with a recent yet completely disconnected tweet:

@mheusser @augeva Sounds to me like another Agilist who is discouraging testers from being testers.
— James Marcus Bach (@jamesmarcusbach) October 11, 2014

This tweet was a reply to sharing a post with an insight that it appears that most people would really not seem to yet get what agile + testing is about (http://mysoftwarequality.wordpress.com/2014/10/10/testing-the-big-agile-misunderstanding/)

But it also reminded me on the idea that other than wanting to call testers developers (or get everyone to code), there's a lot of things I've learned working with agile. Including the idea that having a tester in the team can be harmful and that some teams actually are very successful - really - without a tester. And that the stories of the latter will continue to inspire the recruiting managers to the extent that they are not hiring non-programmers to some organisations.

Tester role can be harmful

I work with an agile-aspiring team as a tester. The idea of shared responsibility for testing in the team wasn't a hard one, as there's so much to test that we need to share the work. I took upon me the ideas of not being a tester (only), but a testing coach for the team - and a coach of all sorts of things that could help us be better together. The developers I work with don't seem to excel in testing, judging from the numbers of problems we need to catch - on average 4 issues / day every day of the year for one tester. But looking at things openly I have a few observations that conflict my own conclusions of tester importance.

1. Developers turn into pretty good testers just by sitting next to them
2. Removing me after I have been there improves quality
3. Testerless teams have delivered really good software

It would seem to me that a big part of why testers are needed is that we allow current developers to rely on externalizing this responsibility. Externalizing the responsibility is a way to make sure testers are needed. And since I sincerely want the best for my organization, I need to think if having a tester around is really that, regardless of this being a core thing for my personal happiness.

Agile teams rely on feedback. The feedback could come from end users, by improving the relationship we have with the real users so that more of them tell about their negative perceptions, regularly. The feedback could come from logs that allow us to see the troubles of the end users, even when they choose not to share their experiences. And we make choices to change the dynamics by investing into systems that allow us to release software to subgroups of end users risking different users to the impact of software that does not work. Small incremental changes are a game-changer. And it has impact on what testing our organizations are willing to invest on. Developers can test too. They can learn to test if they can't test now. And with the continuous feedback, they might actually get really good at testing.

Of course there's a but...

There are teams - plenty of them - that are quite like my team's developers. They're lacking feedback since aspiring to be agile is not enough, you really need to work hard on building the ways of getting the feedback. If your product managers comes and tells that "I did not know it was possible it could work when I start using it", the expectation of quality that team could deliver is very low. If they don't know to expect more, the feedback on the lack of quality is almost too kind to be changing anything with respect to how the team works. If your end users call after a week of your system not working for them at all on a relevant area saying "I thought it might just start working in a few days without me doing anything on it", you're not really talking with your end users to get feedback, but you've trained them to accept almost anything.

There will  be junior developers, who have not learned yet to program, let alone test their own programs. Focusing on all these skills at once is overwhelming. There will be junior testers, who will never become the great testing coaches we would need, since they will not have enough time to think of testing - they're required to grow to be developers. And developers will need testing coaches, exemplary testers to catch ideas from.

Being a junior developer isn't just about years in development. Some people can write code with the copy-paste method after 20 years of practice and that type of code tends to break in real use and be very hard to fix as there's no copy-paste solution. And some organisations will have to settle for now with these developers, as finding better ones isn't possible. So they find one of these, and compensate for the lack of skills by having a tester around.

As much as being a tester is relevant for my happiness, I've met developers who find that not thinking about the end user too much is essential to their happiness. Details of code are beautiful, and the people stuff (people using the software) are just not so interesting. Luckily, there's others who feel the other way around, and together we can be happy and do great stuff.

It seems to me we are discouraging testers from being testers. We encourage them to be test coaches. Use a little less time on testing and more time making sure everyone learns. Share. Use the special superpowers to enable others. And we just really don't need as many test coaches as we needed testers. Which also means we have to realistically say that the tester / test coach jobs will be harder to get. Employees won't be in the lookout for testers in masses. Too many good experiences of not doing so. Including cases where testers were completely left out and new generations of developer-testers emerged.