24 September 2015

What I Learned on Tour

When you think about doing your own Software Journeyman Tour I guess the most interesting questions is what you will learn. After all such a tour is mainly about learning and seeing how other people work. The time (and money) put into such a tour should be worth it.

My Expectations
To be fair I need to discuss my expectations first. In retrospect my expectations were not clear. I did not follow Daniel's rule and had not defined an explicit learning goal. (See my previous discussion on how to go on tour for details.) I had expectations that I would pair with fantastic masters of our craft, who are much superior to me, and see astounding things. That was not measurable and definitely not clear enough. There was no goal and I did not align my plans accordingly. Obviously my expectations were too high, sigh.

When starting my tour I knew TDD well and had been developing professionally since more than a decade. In contrast to that many of my pairing sessions were basic. I helped developers to create their first unit test. Maybe I should have done the tour five years earlier. Daniel even proposed that the perfect time for a Journeyman Tour might be for young developers with two to three years of experience.

Lina Bo Bardi, SESC PompéiaA friend called me a master and remarked that masters do not go rounds any more. They do not learn like that (Smi's rule). I am no master but there seem to be diminishing returns for a learning tour if you are already advanced in some areas. Some coder friends have also expressed this concern.

Concrete Learnings
To give you an impression here is a list of all concrete learnings of the first and second week. I spent ten days pair programming with four different people in this time. While it is hard to express the real learning, here are the things I found interesting enough to write down during the sessions:
  • Learned about little HTML5 games and their way of publishing and making money.
  • Brushed up my IntelliJ IDEA short-cut knowledge.
  • Improved my Mechanics of pair programming, how to deal with exhaustion and zoning out.
  • How to handle dependencies with local and shared lock files.
  • Startup developers are "poor" creatures because they support their customers, do operating, fix bugs, help less technical co-founders and have very little time for actual development.
  • I coded Python for the first time - or more accurate - paired on Python code.
  • oh-my-zsh with plugins is an useful shell extension.
  • I relearned Vi as it had been many years since I had last used it.
  • I paired on existing C# code for the first time.
  • The "Rename Overloads" is a nice function of Visual Studio (or Resharper) that I had not seen in Java yet.
  • When the current Pomodoro finishes, run the tests.
  • I learned more about dependencies of OSGi bundles and their problems.
  • Deploying OSGi bundles in an OSGi aware server is a real pain.
  • It is possible to create a cash flow calculation and business plan in a pair as well.
If I multiply these items with the total of 13 weeks, I get around 80 to 100 interesting things I saw. So yes, a Journeyman Tour is a great way to see many things. I worked on many things for the very first time in my life, e.g. I had never even seen Python, C#, VBA or Typescript code or developed for Google App Engine or opened Netbeans etc. I gained lot of experience on many different things in a short time. Maybe the experiences lacked depth. For example how much learning can you expect from two days Typescript? I spent a maximum of three days in a company working with one or sometimes with two different developers. Maybe I should have worked at least a full week on one topic to get deeper insights. Daniel spent a whole week at each host and considers it the perfect length for a Journeyman visit.

The tour gave me a lot of practice in different areas, maybe I had even more practice than learning new things. I had little pair programming experience before. On my tour I pair programmed all day, each day for almost three months. That improved my pair programming skills by far. In the end of the tour I was able to get in sync with a new pairing partner quickly. Since my tour I love pair programming. I feel stupid when working alone, so I rarely do it nowadays.

Next I practised getting productive in a new project. By running Hackergarten in Vienna for more than a year I was already comfortable with that. On my tour I figured out how to ask for the right amount of context without slowing down my pair with too many questions. Today I am confident to be productive in a new project or technology within a few hours - with the help of a pairing partner who knows the area of course. This conforms to Corey Haines' observation that he learned most how to start with an unfamiliar code base immediately. While this is very helpful for my current occupation as Code Cop and Freelance Code Mentor, I do not know how much this would help you during regular development, where you stay in the project for months of even years.

Luxury Gold Ring Designs For Golden JewelryValue
I understand the value of practice and like working on code katas and other practice exercises. Still my improved IntelliJ IDEA short-cut-fu feels less valuable than working in Typescript because there was nothing new in the former and everything new in the later. I know that my feeling is wrong. The mastery of IntelliJ short-cuts is important and helps even when working in other languages (as long as I stay with JetBrains products) while the basics of another static, object orientated, main-stream language are forgotten soon (unless I get into a real project, which I did not).

Some of my learnings were not interesting, e.g. creating an Excel cash flow calculation was not what I expected to do nor had ever wanted to. Working with my pair on the tasks he or she had chosen forced me to a few boring things, that I hated and would have never done on my own. It was painful but definitely broadened my horizon. Maybe these are the most valuable experiences because I would never get them otherwise. Or maybe these experiences are useless because I will never do such things and I wasted a few days of my life. I am unable to decide.

My expectations partly fulfilled by learnings and practice, which both have a vague value, result in a certain feeling of satisfaction. Still many questions remain. Am I satisfied with the outcome of my tour compared to the time and money involved? What is the value of the things I learned? Could I have learned more useful things in a shorter time? And even if, would I have learned it (or done something else instead)? Maybe more interesting to you is if you would be satisfied with such a tour?

So let us look at some hard facts again. Before my tour I got in touch with 32 companies. During the 60 days of my tour 16 companies hosted me and I paired with 26 people. I further attended two conferences and 15 user group meetings in the evenings. My overall statistics shows me 40% of great pairing sessions which were awesome and where I had insights into TDD or a lot of fun. Then there were 40% of tolerable pairing sessions which were sort of OK. The remaining 20% were bad sessions, where I did not learn much or even felt like crying. It is true that you learn from everybody, even from very beginners, but e.g. handling difficult people was not on my list of learning goals.

Even with some of my expectations not satisfied, my Code Cop Journeyman Tour was one of the most interesting and most intense times of my life. Its overall experience was awesome. Half of the time I did great work while pairing with amazing people. I learned around a hundred new things and had a lot of practice. In comparison, had I stayed with my previous employer I would have experienced a few great days and learned a few new things during regular work. The tour made a massive difference for me and I am glad I went for it. Until today I plan for single Journeyman visits from time to time. Last year I spent three days pair programming for food. While this is less than 2% of my total work time, I am still proud of myself that I kept the spirit of the tour.

just do it.Final Recommendation
If you came here to check if it is worth to go on tour then my answer is yes. A Pair Programming Tour is a great thing to do. Even if you go for a single month, visiting only four companies for a few days each, you will see a lot of new things and work with people you never worked with before. It is the right thing to do. Now go and do it!

17 September 2015

How to Journeyman Tour

It has been two years since I did my own Journeyman Tour. It has been a blast but I never took the time to write about some topics besides the actual things that I did back then. Recently I was reminded of the topic by Lennart's tour and friends asking me about it as well. So I need to catch up and discuss some of my findings. This article is not about the tour itself, but about things to be considered if you plan your own Journeyman Tour.

What to Expect
Back in 2013 I first analysed Corey Haines's Pair Programming Tour in 2008 to get an idea what it means to do such a tour. Then I defined my personal, particular rules of my own Code Cop Tour. My rules were supposed to reduce uncertainty and help me achieve my objectives, but they were not specific enough. (I will write about that later.) During a Journeyman Tour one objective is about learning, so you need to define your learning goal (Daniel's Rule). Maybe I did not have that, or I had the wrong one, or my other tour preparations were not aligned with my objectives. More discussion would have helped me to get a better picture what might happen during a tour. So if you plan to go on tour yourself, I recommend you discuss your plans with people who have done it before.

Planning sessionPlan Ahead
First you need to select the area you want to visit. I stayed local in my city. Others toured their country or continent and a few visited the whole world, e.g. working at companies both in Europe and the United States. Adding conferences as speaker or attendee is a great thing as well. Based on the decided locations and dates I created a schedule. Be aware that a Journeyman Tour, while being a great thing to do, is also exhausting, and in fact hard work. You need to plan accordingly. I had planned too many sessions in too little time. You need to plan for some free time each month as well.

Host Companies
Finding hosts is the hard part. See my list how to find hosts and sell a Journeyman Tour to management. Some hosts have specific legal requirements. You need to be prepared for some legal hassle. In Austria and Germany the legal background for unpaid work is the Volontariat, which is primarily used for education. But I am not a lawyer, please do not ask me for details.

Silence PactSign Non-disclosure Agreement
All larger companies asked me to sign NDAs. I signed them because I was not interested in their customers, products or other details. I wanted to see the way they worked, how the used technologies and the engineers working there. I even brought a generic NDA with me if a small company or startup did not have any template. I respected the agreement and did not talk about any details we had worked on ever. That is the reason that my reports of the tour are generic and lacking details. I always asked for permission to mention the company in my blog and let them review and approve my posts before publishing it.

Respect the Host Company (Security) Policies
Having worked at large corporations I understood the need for security of most host company representatives. As they had no idea what a visit of a Journeyman meant, they had concerns. My rules were never to work alone. Beside security concerns it helped me keeping focused on pair programming. Obviously I did not need any access codes, passwords or other security related information. While I brought my private laptop to take notes, I even asked for permission to plug it into electricity. Some companies do now allow private IT equipment to be operated inside their premises. While most of these issues might sound silly to you, it is of utmost importance to make potential host company representatives feel secure if they are going to allow an outsider in. Further I wanted to respect any company policy of the host while I stayed there.

Finding a Future Job
Working for some time at a company is a great way to figure out if it is a place you would like to stay. Some host companies even implied that depending on the report of my pairing partner they would offer me a job. This could lead to problematic situations. If I would not apply for a job after my visit, it would be like saying "your company sucks". A company hosting a journeyman is always a great company. I recommend rejecting any discussions regarding future jobs by saying that your visit is not about a job but about learning and sharing (Thomas' rule).

My Piggy BankExpect No Compensation
Some people asked me if it paid off to go on tour. While it is possible to have a paid tour, all the Journeymen I know did not get any money for their work. The classic Journeyman Tour is a self-funded journey of discovery and sharing. Even when provided with food and a room to sleep, a tour is not a cheap trip. You still need to cover additional costs, e.g. public transport. During my tour one company wanted to pay me because they were afraid to be accused of unreported employment. In another company the team lead had to pay for my lunch himself because it was impossible to get the money from the company. When I was away from home, I asked the host company to pay for my hotel at least.

Journeyman Work
Daniel told me this story: During his tour in 2013, a company showed interest in hosting him. When discussing terms of his visit, it turned out that the company wanted to get professional training for free during his visit. As working together and sharing knowledge is the base idea of a Journeyman Tour, it is difficult to draw the line between regular exchange and abuse. But extensive training of the host company's stuff for free is definitely out of scope. During my tour I pair-programmed (and pair-designed and pair-tested) with developers and occasionally gave a presentation about the background of my tour. In one case I prepared a presentation of the things I had learned during my visit. I did not engage in any other internal activities like facilitating internal Coding Dojos or giving presentations on other topics, and nobody asked for it. Wherever you draw the line, you should think about it before starting your tour.

That information together with my older articles should get you started in your own Journeyman Tour! Read more about the tours of other people, e.g. Daniel Temme, Andy Waite and recently Lennart Fridén.

31 August 2015

Empowering Testers

Developers need to be able to test
I strongly believe that we (software developers) have to be able to test our work. How else can we make sure that "it works". At the minimum we write unit tests for the code we just created. The whole idea of Test Driven Development is based on finding, prioritising and running unit (and sometimes acceptance) tests against our code. Even people that do not like TDD, put a strong focus on automated tests. Paul Gerrard recently put it nicely as "if they can't test they aren't developers". Unfortunately not all developers are able to do so. I often meet young developers who have no experience in deriving test cases from requirements or finding more than the most obvious test scenarios at all. They write tests because they want to make sure their program work, but their tests are not focused, testing too much or nothing at all. More skill and experience is needed.

We can code it! (for Mother Jones magazine)Need testers be able to code?
When developers need to be able to test, do testers need to be able to code? This is an old debate. As hard-core coder I believe that testers need to be able to code. Period. For example at one my of previous employers, the testers were asked to automate their tests using Rational Function Tester. They had to write Java code to drive the test engine. And the code they wrote was abysmal. I do not blame them, nobody had taught them how to do it. But the code they wrote was important for the project's success, so it better had some quality at least. What was needed were Test Automation Engineers. As the test automation code is much simpler than the regular code, there is no need for explicit conditionals or loops in test cases, I concede that these testers (the engineers) do not have to know as much about coding as developers do. They do not have to know Design Patterns or SOLID principles, but they need at least to know naming, duplication and to a certain extend, abstraction.

Manual testing is immoral
Uncle Bob has explained years ago why manual testing is a bad thing. Probably he meant that manual checking is immoral, because the testing community likes to distinguish between aspects of the testing process that machines can do (checking) versus those that only skilled humans can do (testing). As there are more than 130 types of software testing, many of them can only be done by a skilled human, e.g. exploratory testing. I do not know how many testers do these kind of interesting things, but most of what I see is either (immoral) manual checking or test automation engineering, which is kind of coding.

Austrian Testing Board
Earlier this year I was invited to the Austrian Testing Board to give a presentation about Deliberate Practice. While Deliberate Practice is popular with developers, e.g. Coding Dojos or Code Retreats, it can be applied to all kind of learning. For example there are Testing Dojos and Testautomation (Code) Retreats. My presentation was received well and I enjoyed a heated discussions afterwards because - of course - I had provoked the "testers" a bit ;-) One of the attendees, Gerd Weishaar, was surprised to hear about my approach: Doing TDD, automating all tests (because "immorality") and running only a few integrated tests (because Test Pyramid and Scam). I also told him about my hate for UI test automation tools because of their brittleness. As the VP Product Management at Tricentis, a company focusing on software (end-to-end) test automation, he had a very different view than mine: Almost no developers writing unit tests, groups of testers who work offshore, doing manual testing. We immediately became friends. ;-)

Empowering Testers
Gerd's vision was to enable the testers who are not able to code, empowering them to do their job - to get something tested - without any technical knowledge. Despite our contradicting views I got curious: Would it be possible to test for example a web application without any technical knowledge? How much technical background is necessary to understand the application at all? How much automation can be achieved without being able to write a script? And most interestingly, how much support can be put into a testing tool, just by making it usable for the testers. How far can we go?

Magnif-eyedTricentis Tosca Testsuite
The tool Gerd was talking about was Tosca, a functional end-to-end testing tool. I had heard about it but never used it myself. Gerd encouraged me to have a look at it and provided me with online material, but I failed to allocate time for that. In the end he invited me to one of their monthly instructor-led training, free of charge. Although I had never planned to dedicate three full days (!) to checking out Tosca, I accepted his invitation, because I find well prepared instructor-led training an efficient way to get started with a new topic. The training was tough, three full days working the tool on various exercises. The trainer and the other participants knew a lot about testing and we had great discussions. (If you need to work with Tosca on your job I strongly encourage you to take their instructor-led training. Afterwards you will be productive using the Tosca Testsuite.)

Small Disclaimer
I attended the three day training free of charge. Gerd asked for feedback and a blog post about it in return. This is this blog post. I liked the trainer and in the end I liked Tosca, so I am positively biassed. Still all the open questions from the beginning of the article remain.

I had two goals for the training: First I wanted to learn more about the mind-set of "classic testers" and second I wanted to check Gerd's idea of empowering non-technical/non-coder testers. Tosca is very powerful. It includes tools for project planning, risk management, test case design as well as manual and automated testing. It took me three days to get an idea what the tool is capable of. I do not know how much more time one would need without the development background that I have. I am used to such kind of tools, after all Eclipse or IDEA are not easy to use either. So training is necessary to use Tosca. Maybe three days are enough to explain it to someone who has no idea about coding, maybe five days are needed. Anything less than ten years will do. As the tool only offers a fixed limit of combinations, it is possible to get familiar with it fast.

Context Sensitivity
Tosca is a professional tool. The user interface is well done and it supports power users by providing tab ordering and consistent keyboard short-cuts. Unfortunately some of its many options and functions are really hidden deep in dialogues or require you to type in certain text combinations. This is not usable in the general sense. I guess developers are used to writing text, after all that is the code we write day after day. Still we expect context sensitive help and code completion, something that non-coders need even more. So I guess there needs some work to be done in a few places, but that can be fixed easily, and Gerd told me they are planning to improve this.

Tosca Test Case Design
The coolest things of Tosca is its Test Case Design functionality. It enables the formulation of abstract test cases, working with happy path, boundary values and negative cases, to create a conceptual model of all tests necessary to cover the given functionality. While this modelling does not involve any kind of coding related skills, it definitely requires skilled test professionals with analytical thinking and a high level of abstraction. As I consider these skills important coding skills, the test case design requires at least someone "like a coder".

Tosca Test Automation
While it is possible to make test case organisation or execution easy to use, the real problem is always the automation. I cannot imagine a non-coder being able to create reasonable test case automation. To hide complexity, Tosca's automated test cases are constructed from building blocks which hide the real automation code, e.g. pressing a button on a web page. It might be possible to create an automated test case just by arranging and configuring the existing automation steps in the right order, but usually that is not the case, because new automation steps have to be created on the fly. Also the test automation allows for conditionals, repetitions (loops) and templates (macros), which are typical coding constructs. If someone has to work with assignments, conditionals and repetitions, she is already a programmer.

Where to nextHow far can we go?
The underlying question is if it is possible to lower the requirements for technical work by providing smarter user interfaces that support the way we work? I hope so. Enabling people to get some tests automated without knowledge in coding is a good example for this. Even if we can make the tools just a bit more usable our users will feel the difference. Tosca contains some interesting approaches regarding this. Reducing complexity lets users work on a higher level of abstraction. Unfortunately abstractions are sometimes leaky and suddenly we are back in the low level world and have to type "magic" text into plain text fields. For now there are still areas in Tosca where you need to be a coder and you have to stick to software development principles to get good results. But I like Gerd's vision and I am curious how far they will go to empower non technical testers.