Kids Creating with Computers vs. Coding

  

My son, soon turning 7 years, started on 1st grade in school. It's been a great excuse for me to think about things I haven't thought about so much, both past and future - and my actions.

PAST

Starting from the past, I've looked into how I ended up becoming a software professional with a more specific label of identity: 'tester'. I remember a few core turning points in my childhood.

Chronologically, first one is remembering that our family had a computer (Vic20, Commodore64, Amiga ...) that I absolutely loved. However, it wasn't discussed as family computer, it belonged to my younger brother. Not necessarily because he was more interested, but because he was a boy. I remember asking permission to use it, finding slots of time when it was available, always being the second one to gain access to the computers. The chances of learning stuff on the computer were limited at an early age.

Either my parents were trying to be fair with the access on the computer or my brother was able to share, but I remember having my time on the computer. I learned English on Sierra's games at an early age - I absolutely loved comping up the right words to progress. I bought MikroBitti-magazines with printouts of programs I carefully typed into the program for the Commodore64 and I remember being extremely frustrated with a bug that prevented me from running the software I had "created" - copied really. My early experiences were successes with understanding how (and why) software doesn't work.

I have forgotten about my courses on computers in school, but I remember my first programming course. We could do whatever we wanted, and me and my friend paired up to create a Pascal program that implemented some girly magazine questionnaire "Test if you are popular". I was really proud on the splash screen silly graphics but remember how silly structures I created for the conditionals needed for counting the points in the actual questionnaire.

I was never told I couldn't do something. Then again, I wasn't pushed to do stuff with computers either. And the more I liked computers, the more weird I was. I had my friends - large group of them, I was never lonely - but I was never popular either. My reference group allowed me to like math, physics, chemistry and eventually, computers.

FUTURE

Now that I have kids, I want them to have a chance of learning to create, not just consume, on computers. They've played games at an earlier age and learned to click dialogs to progress without knowing what the text says. Quite different from me working with the English dictionary to play through King's Quest. I see that they are, at a young age, turning into more of consumers of technology than I ever was. Introducing creating is something I need to help with.

Also, my daughter makes me suspect that with the social nature she has, she will not be interested in creating alone. And what still often happens is that when we teach code and computers, we teach it as individual skill. With her friends telling soon enough that something is not cool or girly enough, she is sure to go with the crowd. Thus the future needs changing the crowd.

The future in Finland seems to have Koodi2014-project - first graders starting in two years will get taught programming. Both my kids will be out of the first grade system before that.  Reading the materials created to support the project also upset me with the code-centric attitude. While I think it's great to give kids the chances of experiencing that they can create stuff by coding, I'd also want them to get chances of creating stuff for computers by not coding. The software professionals today and in the future don't all code or don't code all the time. Reading the guidebook for teachers, I get the sense that we're starting to teach not valuing the non-coders contribution: the salespeople, the product managers, the business analysts and domain experts, the graphic designers, and my kind, the testers. I already have to listen to programmers creating unworking software (well, works on THEIR machine in THEIR use case) being better than others because they code, I would rather have the future teach kids collaboration and value of different skills in creating working software.

MY ACTIONS

I decided on my personal actions already in spring. I contacted my son's school's headmaster to suggest that instead of waiting until 5th grade for computer club to start, I volunteer to run one for 1st graders (and 2nd graders next year so that both of my kids get to be in). They welcome the idea, without knowing much of the contents.

I want to focus on creating with computers, in collaboration. I want us to do artwork together, add audio and put things together in very lightweight programming activities. Perhaps create ideas that are not given as "create this by programming" but creating something they could come up with. We'll do some code.org exercises and some testing exercises, also probably a bit of agile practice exercises. I'm sure different participants contribute different aspects with the idea that creating software is social group work where we can build on the others skills and ideas.

So, no "code school" for me. Code shouldn't be placed as the hub of it all. If we are "missing 17000 professionals by 2016" from software, not sharing the work with different people with different interests (other than code) is not going to help us.  I want software skills to be taught more inclusively. Code is included. But a lot of other interests that people may have should be included too.

Pairing to slow down a developer from starting new items

My last two posts have been about small batches and crazy reasons that make small batches take a long calendar time. As usual, I wasn't happy with just saying I don't like how things were, I needed to try something different.

First, I sent an email to the developer and our manager suggesting that I have two ideas of how to slow the developer down after done-without-testing as I felt that taking another task when this one was not yet really done was premature and source of problems. I suggested to:

1. Allow the developer to spend time studying instead of moving to another interesting feature he would not like to come back from. In general, the option of just moving to another task should be less tempting and the realization of getting quickly back to the thing that isn't yet done should remain the priority.
2. Make the developer responsible for the testing task following the development task, with the realization that he will need to invite me to pair up with him to do it well enough for now. 

The option to choose between the two wasn't real. Number 2 was the only real option. Number 1 was to emphasize that we actually were supposed to have a rule on limiting work in progress.

So today, the developer walked up to me first time asking me to test with him. So far I've been the one polling for a proper time and done that way too rarely. We sat down with two computers and two browsers, and started testing.

With all the issues fixed from last round, I asked if he was confident in the feature now. He said he wasn't - because there was always something I would see that he just didn't. We talked about the starting choices of what to do first and why, and he seemed a bit puzzled on my way of thinking - the problem area seemed more condensed to him with less links around the product.

We found problems in the changes he had just made, and we went through how it should work in different scenarios testing it through. He would take a pause from testing, fix things in code and deploy a new version that made things better.

When he seemed to think we were done, I wanted to try a few more things. Just because I just thought they could be connected and I had not tried them yet. We found problems specific to IE9 and how data (unneeded null values) got saved in editing scenarios. We learned that there was a connection to history feature that was forgotten during development and did not work. And that there's a multiple selection feature that this feature wasn't compatible with.

With a few hours of testing, we looked at the problems we now knew and agreed it would take a bit of time to come up with how to deal with them, and alone time might be useful. Before we parted, we still tested the other feature he had been working on that left me waiting on Monday and found no issues. And agreed we'd spend an hour together on each feature he completes from now on, because it's just more efficient and fun.

Need to keep reminding the developers that they can't outsource quality to me. Even if they know I will find problems they miss, that just isn't acceptable approach. Collaboration is good. 

Need for Speed, Motivation is the Key

Based on my previous post on waiting and having business value items in the inventory of unfinished work for a long time due to juggling to other work, a colleague in twitter left me thinking about batch sizes.

He pointed out that with a small batch size, the wait time would be shorter. It's a great observation, but also in my experience, one of the most misunderstood principles in practice.

What is a small batch? I would think that is the smallest possible value you can add, for now, into the software. A batch is not a task. It's not that you've done "design" for something, but you need to go through all the layers to actually have the resulting value in production. Small  batches are the heart of incremental development and delivery, and from a perspective of testing, I would claim I've been getting better to help my teams find the smallest possible things we could add.

The challenges with small batches tend to come with the tasks some people refuse to acknowledge. Like testing. If there's a really small change, adding six lines of code, it shouldn't take long to get that tested, right? Unfortunately, quite often the view into the system as delivering value connected with all kinds of things means that the very small change isn't a small one to test. And in particular, it isn't a small one to fix, as one (or more) of the connections were completely dismissed in the implementation. There's a very relevant, common use case that just wasn't in the focus of the change now.

So, small batches to some may be bigger to some others. And these surprises in how they are sized up are causing the waiting problems, as one has already "moved on", when more work on the same small thing arrives. The developer never committed to complete the value, just his idea of what tasks would be needed to deliver the value. And he is mentally engaged on the other tasks already when he is told, with examples, that it just isn't done yet. The message is not welcome, leading to a wait time.

This all is a vicious cycle. It eats away morale of us all. The tester, the developer, the manager. None of us is happy. So how we don't get it changed is a mystery to me.

There culture includes a "need for speed". Doing things continuously, incrementally fast. Just add more. Change it. And don't break it while changing. There's no test automation to support this. The building block of speed is the developer, who is pushed for finding a minimal solution that could be delivered quickly. The ideas of someone testing are new and are mostly making things worse. The time was already up by time of delivery, and now the poor developer has fixes to create, while feeling the pressure of the next quick feature is the queue. And often not just the external pressure but also internal - the next feature is more fun that fixing the old one.

Let me look at a small batch from one more angle. A really small batch without big testing implications that would look like an hour of work - it takes three days. Or in other words, a work week fits just two of those types of issues. When a developer is pressured with time, they learn to protect their other interests. The motivation is low as you're all alone with your assigned task, and you might not have the skills to come up with a solution. The first day goes into just procrastinating with the idea of having to do this. Google a little, read whatever you find, talk to your colleagues. Not directly on the matter of course, otherwise they might say that you're not good enough. The second day you try out some of the stuff and none works. On third day you ask directly someone who knows and can complete the task in an hour. And after the other developer did the actual bit, you spend time testing, checking and finalizing, as your name will still go on the fix.

I believe that while the idea of small batches is great, the relevant bit here is to do something about developer happiness, motivation and skills. There's a reason for any of us rather spending time procrastinating than working efficiently towards delivering the value. The pairing and other changes I suggest threatens the hidden self-development time. It threatens the permission to work remotely and not talk to your team mates for days. But it also holds a lot of potential to make us happier, all of us in the team.

How many "small batches" does your work week fit? Doesn't the whole concept of small batches make you feel bad about not completing so many of them in your week? I love the idea for trying to split things rationally from a value perspective, but I hate the work monitoring implications.

Not all batches and skills needed in them are equal. Not all days for a professional are equal. I'm great at procrastinating, letting my mind wander and building connections that wouldn't be immediately relevant for the task at hand. But the stuff I'm learning and realizing while at it, makes a big difference in the end result. But I also finish the work. Sometimes when I was supposed to. Sometimes early, sometimes later. Motivation and feeling the purpose make a big difference on whether a small batch is small in actual calendar time.

Experience on how to turn testing into not fun

I'm back from vacation, with new energy and the old love for my profession in testing. Testing is great, it's fun, it's challenging. Except when it isn't.

I started off with (re)testing a small feature I had noted that didn't work in so many ways just before my vacation. Instead of us getting the feature finished and a feeling of mutual success on making a delivery, I was told that it would be fixed while I was gone. Well, some of it was fixed, but in general it still doesn't work. The users could not do valuable work with it. It doesn't work in real scenarios.

I talk with the developer to hear that the stuff I had reported before are "special cases" - relevant to the user, but all requiring logic he just hasn't yet implemented as he thought it would be special. I mention the new problems and they are deemed "weird behaviors" - we do agree. I'm concerned of the severity of the issues for the end user, blocking the delivery of added value. The developer seems to be concerned with the technical challenge of it, how could the code do things like that. I just know it does, from experience.

I ask if the developer tested the feature himself, if he actually uses it and he tells me he does. The blatant difference in our experience calls out for pairing to test it, to share the experience. With the new energy, I'm about to suggest that.

But, just before I suggest pairing (which isn't a normal way for us to work, sadly) the developer points out that he has started working on another task that will take him days to weeks and that he will not look into the "weird behaviors" before he's done with the other work. I remember again what really frustrates me - unfinished features waiting in inventory. Features that don't improve while they wait, features that get more broken when they are "fixed" after weeks of wait time. And the repeated experience of testing something that doesn't work for me, but presumably always works for the developer.

Waiting sucks. Finding easy bugs sucks. Not collaborating sucks. This isn't testing, this is starting testing again and again being blocked right in the beginning. Testing would be great. I hope I get to do more of that soon.
 

Learning to code - just learning

I'm reading Cem Kaner's book on Domain testing. Having skimmed though a lot of it, I started again and got stuck with ideas from start of intro.

"Testing is a cognitively complex activity. Developing competence with cognitively complex skills requires mastery of routine tasks and formation of schemas (cognitive maps) that can guide you as you do tasks that require more conscious effort (van Merrienboer, 1997)"

I've dedicated much of my adult life to building these skills and building networks that help me develop these skills. Right now, on my summer vacation I'm putting 20 hours a week for four weeks to a course that teaches one out of hundreds testing techniques - thinking tools. I absolutely love the BBST Domain testing course so far.

Testing is cognitively complex activity. So is coding. But they are different cognitive activities. When I do things, I want to be good - excellent even. With all the effort that learning testing takes, where to find time that coding takes?

The question on my part is really rhetorical. I was forced to take coding classes as part of my MSc studies for computer science. I could do them, but I never felt the urge to do it again or do more of it. Looking back, I wasn't into the things we were supposed to implement and I never felt the same overwhelming feeling of success in a brain-engaged activity that I get with testing, again and again. Recently, I've been giving coding a second chance and with the control of choices learned in testing, it's definitely more fun. But I still don't get the feeling of success that would drive me to depths that testing has.

Creating an algorithm that handles things smartly is somewhat of a boost. But I do that for testing too, to build ideas of what's possible and expectable. I just skip implementing and debugging the idea if I test. I love thinking about the problem and solution, but I lose interest snd have to force myself to complete the details on different layers of logic - the routine tasks of coding. It comforts me a little that I learn while doing, that I see ugly code that just cries to be refactored. That I get reminded that coding is just as much exploration as testing. But it still doesn't give me the feeling that THIS I want, this feeling is totally worth all the effort. It does for some, and I respect their love of code highly. I just feel different.

A lot of the cognitive load on learning coding is like the stuff we now do on the domain testing course. Learning routine ways of doing things that repeat, to free our minds to the non-routine aspects of our work. I notice my routine with coding is off, I need to rely on guides (intellisense) to come up with syntax and I google like crazy to decide what library would already have something useful for my purpose. I don't remember since with choices of time, my practice of coding just isn't on the level I'd like it to be.

With all this, I find the 'testers should code' 'why would a tester not learn to code' a generally upsetting theme. Why should I want to be a mediocre coder when I can be a brilliant tester? Or why should I give up my aims of excellence in testing to learn coding to a level I consider professional?

On my team, most developers suck at testing. I know from a personal experience that the 'can't break own stuff' is mostly just an excuse to avoid work they don't love. As I ask developers to test more, I offer to implement more. Neither gets the things that would make us fully happy, for supposingly greater good.

I just keep wondering if this trend is really smart at all. Let testers learn coding but let them also be non-coders. This direction of emphasis would lead to driving away more good testers. You don't know what you're missing since those who think this is a smart move never paid attention to what the 'business people' do. It's not coding, so it's probably 'less valuable' - as one of my developers put it.

Coding is great. Testing is great. Finding idea-solution-product-market fit and buy-in is great. We need respect for diversity and collaboration more than super-individuals that have these all.

Let my colleagues in test not learn code in peace. Like James Bach said in twitter: not everyone wants kids. Choices and preferences should ne respected, not continuously feeling attacked. If coding is in demand, who should learn and change: those filling the demand (testers who code) or those (mis)identifying the demand (recruiting managers)?

Surely recruiting managers can go ahead and recruit for skills they need. But it just might be that emphasizing one they lose out on what they really need. But since they don't have it, they might not realize to miss it.

Continuous delivery without test automation, first experiences

It's been a few months since I managed to get my favorite team at work talked away from Scrum and story points into a Kanban-like continuous delivery of an item at a time. There's a long way to go, but first two months are a good point of looking back at some of the things that happened.

Giving up on size estimates

The driver behind the change for us was the frustration with size estimates: story points and hours alike. We observed that the size did not really matter for us, and the ritual of sizing things up was draining our energy. In particular, if there were surprises, things to be learned while doing, we easily ended up with unproductive discussions of how the thing was understood when sized up and how it is understood now as 'requirements changed'. If the team understood the problem, solving it was design. If they did not, solving it was requirements. The externalizing was unhealthy and unproductive.

I kind of like the change in discussions this caused. Instead of sizes we talk of when could I help with testing it and where, and if we can split it into two (or more) deliveries that would already bring value to the end users. Not very good at that yet, but we had not done any of that before the change.

Releasing regularly

In an earlier post, I wrote about the feeling of ease with making releases as they are done continuously. It's a routine, not a hassle. While our continuous delivery does not (yet) rely on test automation, we're not as fast as we could be in making a feature release-ready, but we are capable of analyzing our changes  one by one, thinking of likely side effects and testing manually. And isolating a feature at a time makes it much simpler to understand what caused problems. I really loved last Thursday, when the build completely broke with two lines change that was the only thing in the build we were working on towards the release. We jumped right in to solve the surprises that none of us could foresee.

The two months also taught us about releasing regularly through trial and error. As Git and team talking to each other about what we do was new, we had at one point two significant changes put into our integration branch around the same time and as both had a lot to fix (and test again and again) we managed to block our feature release pipeline for a month, making one "traditional" release, very much like the ones we did before. Single piece in the pipeline bottleneck at a time is great, and it also drives us to think about ways of collaborating to make the bottleneck smaller.

Testing in this all

In testing of this style, there's been ups and downs. When we refactored a major area without automated tests and with time of a developer who had not originally created the feature, testing was somewhat painful as functionalities went missing: the code just had not given out a hint of such an intent being embedded in the old version. I relied a lot on my memory, tested areas I knew like I've never seen them before and digged through a lot of old Jira issues mentioning piece here and there. The specification existed, but was useless on the level of detail that was relevant this time. It was also painful to test the same connected features again and again and again, as a change would easily have impacts elsewhere. It was clear that the model / design of the features wasn't clear, but got clearer.

The good part with this was that some of the lessons learned ended up in automated unit tests. But still not enough. And it drove my focus again towards extending our test automation capabilities together with the team.

While you can do continuous delivery without test automation, you might not enjoy it was a lesson worth experiencing for me.

Back to usual

In the last two weeks, we've been doing releases 2-3 times a week. It's nice and routine again. The developing and testing isn't routine, but making the release is - just as it should be. Releasing more often has also revealed some issues in production that we can honestly say that we would not have thought of to test manually / automate. Fixing them has been quick and routine, and the general build quality in releases has not lead anyone to question the idea of releasing more often. I hope we stay that way.

Single-piece flow will still take us a lot of effort, but some nice agreements on how we organize towards that have already been made. I look forward to starting our pair programming trials in autumn, and working out ways to move from working solo on a task to working as team on a value item. The potential is there, while road will most likely be long and winding. 

A story of a big small bug

This week, after a day at conference and a day home with a sick kid, I got back at the office to test. As I opened Jira and got reminded of recent fixes, I chose an area that I found relevant to start from. The changes were quite extensive as the developer had spent several days puzzled with them. 

I opened the application and clicked though the shortest possible sunny day scenario and the application froze. I could't believe it, so I restarted and it was true. I felt upset. I felt disappointed. I felt that with all the efforts to improve on team responsibility, it just gets worse. I was thinking that perhaps the best way to help my team mates feel responsible would be just to remove me as the safety net - except that did not work either. So I talked with the devs to let them know it doesn't work and blocks me, logged it on Jira and steamed out the worst of frustration in a tweet. 

Then I tested some more, to learn that the first feature I was testing was just a tip of the iceberg. Out of the features I tried, there was one that worked and many that didn't. I realized the problem wasn't with the changes to area I was testing at first, but with common dialog component. As we're a tight team, I realized the issue would belong to another developer, the one with the faulty change. So I reassigned the jira issue. 

At this point, I was even more upset. There was a problem making our application freeze on all actions but the one the change was done for. Not only had the developer making the change skipped testing any other places when changing our dialog component, but he had done the change paired up with another who did the same. And none of the six had used the app in over two days to notice. 

Soon after, there was a quick and dirty fix - by the words of the developer. The final fix would take a little longer. But I was told they're both small fixes, and wouldn't need much testing after. A little later I also learned that a developer had seen the problem, but forgot to mention it to others. At least there was hope, as the whole team wasn't completely hands off the application. Mistakes happen. 

This incident reminded me again about the difference in how I think as a tester and how developers think. When I see a problem, I look into its severity and implications to users. When developers see the  same problem, they look at how interesting or complicated it is to fix. And size of symptoms may be completely unrelated with the size of the fix. 

With the discussions on smallness of the fix, I was left feeling unappreciated. It was a small fix, small effort for the developer. But it wasted a day of my time. How about including my time in sizing up the implications in the team? It would have kept small if there was at least a bit of own testing by the developer before the feature showed up in the common build. Or after. But before it blocked all of my other testing. 

Also, the fix wasn't small to me as I was going through all features in the program for other surprising impacts. While knowing the fix it was unlikely, it was still a possibility. Again some hours of work the developers refuse to take ownership of as it shouldn't have an impact. 

So, negotiating on more test automation ahead. Even if the developers dislike maintaining it.