Mentoring

Mentoring consists of a mentee and a mentor, and a topic on which the mentee gets mentored. While this sounds like a bogus statement, I have found this mentor – mentee model in different places – sometimes with some kind of drawbacks.

In the Miagi-Do school we work with mentors. Well, after you found us, you usually need to pursue a challenge. An instructor will pass you a challenge, and then work you through it, eventually debriefing afterwards as well, and reflecting on your course of action. If you decide to stay with the school, you become a member of our group, and are encouraged to find a mentor if you want to follow up on higher levels. A few years back I was the instructor of Michael Larsen which really knew where his next challenges were, and I myself found a mentor in Matt Heusser through whom I eventually became an author.

But there are also other places you can look out for mentors. Some are offering free coaching on Skype, other might want to be contacted first. The most amazing place I was able to find mentors is my current workplace.

We have a mentor and apprentice model. You can basically pick any mentor for any topic that interests you, and you want to pursuit. Of course the mentor has to take on the additional time for mentoring you. That said, we have developers picking a more senior programmer to extend their skills, or they pick up a consultant in order to master their skills in this direction. Some of my colleagues are more interested in technical topics, others want to dig deeper on soft skills. There is virtually no boundary, as a senior consultant may also decide to be mentored by a programmer. Some of my colleagues even have three to four mentors at the same time.

One thing I found out over the course of the past years. When it comes to mentoring, it’s crucial that you pick your own mentor by yourself. First of all your intrinsic motivation will be higher to work with the one mentor that you picked. Another advantage is, that you can talk to your mentor about his contract with you, what the areas are, besides risking that there is another stakeholder in this game – the one who imposed the mentor on you. When it comes to mentoring the level of trust can not be undervalued. That’s why I picked some of the people I learned from the most outside my workplace. If my memories of the apprenticeship patterns recall correctly, finding a mentor is one pattern in the book. I whole-heartedly took it on multiple levels.

Peer-Groups

In the past year we played around with deciding about salaries. So far we had a system in place that didn’t scale: a group of four senior consultants decided about salary increases. Back in March we decided that every employer has the chance to self-select a group of peers which then work with the employer, and give recommendations for salary increases to the senior consultant group. Sounds crazy? Well it is.

Peer-Groups meet together from time to time, reflect on what the particular colleague did, and try to come up with recommendations for the future. In my particular case, I got some feedback from three colleagues, some of them I implemented, some of them I decided to keep stale for the moment. In our second meeting, I laid out my reasons to not pursuit this particular goal, and got some more feedback with some more goals, that I might pursue or not. So far, I found this group fully worth the time based on the feedback and recommendations I got.

In January we even decided to have a full day of peer groups. We met in the morning, working in a World Cafe on the idea of peer groups. Then we set up a market place with peer groups that wanted to meet and give and provide feedback. Some plans previously laid out were changed then, but we spent a full day with colleagues, talking about peers, how we see each other, and recommendations for further improvements. So far I found this feedback very valuable, nonetheless we are experimenting with 360°-feedback now. So, there might be more to come.

Conclusion

Picking the right mentor, and the right peers to listen for feedback and recommendation can help you personally grow. For both approaches it is crucial to keep an eye on the self-selected aspect of it. If this sounds like selection bias to you, maybe consider some of the constraints we initially put on the selection of peer-groups: at least one peer that is more senior than you are, at least one peer that is less senior than you are. We eventually re-formulated that into: at least one consultant, and at least one programmer in our final discussions, yet the constraints help you to decide about it.

One final thought. I myself consider me to know about the goals and directions that I want to pursuit. There are tendencies which I take up. So, meeting with mentors and peer groups far less is fine with me – so far. I hope to notice the right point in the future to change that. You might have a different cadence for similar get-togethers.

Programer’s survey

Up until know 183 people have filled out the survey.

The first question in the programmer’s survey is on the particular programming the programmers used.

The majority of programmers seem to use Java. There are some using JavaScript, C#, and Ruby. The minority of the participants so far use Visual Basic, Clojure, and Haskell. I think this is is relevant for the remaining answers – i.e. when it comes to the SOLID principles which mostly refer to object-oriented programming.

On the usage of TDD, I received some interesting answers so far.

43% use TDD regularly, 20% at least once per week, 17% about once per month. 17% never use TDD, and 3% don’t even know what it is. This surprised me, as I thought that fewer people use TDD on a regular basis.

On refactoring the picture seems a bit better.

64% use refactoring several times per day; 24% use it at least once per week, 8% about once per month. 3% never use refactoring, while 1% does not know refactoring at all. More than 90% of the people who took the survey at least know about refactoring, and use it on a regular basis – ome more often than others. This didn’t really surprise me, as today’s IDEs – besides ones like XCode or Visual Studio – ship with support for automated refactorings. Probably that’s why so many use them regularly.

The final question in the programmer’s survey referred to the SOLID principles.

48% consider it part of their work, while 32% think about some of the letters from time to time. 25 don’t need SOLID, and 19% wondered about why I wrote it all uppercase. Surprisingly this number is also higher than the numbers I had thought of before sending out the survey. So I was again surprised.

Tester’s survey

The tester survey was mainly motivated by Lee Copeland’s Nine Forgettings. So far 104 people have filled it out.

First of all I wanted to know about the experience in the field. I was interested in the experience of the people filling out the survey, and how this might correlate with the different viewpoints.

42% have more than 10 years of experience, 37% more than 5 years, 7% 4-5 years, 7% 2-3 years, 6% of about one year. 2% stated they started with testing just recently. This reflects a huge level of experience.

Next thing I asked for some testers in the past. Reflecting on Lee Copeland’s presentation, I was interested in how many people actually know these testers.

90% know Michael Bolton, 88% James Bach, 78% Jerry Weinberg. Michael Fagan, who introduced inspections, know 33%, Dave Gelperin, who authored the IEEE-829 standard, know 13%, and Bill Perry, who founded SQE, know just 8% about. I think this reflects some worries from Lee, but I was still surprised by the knowledge about some of the past heads in software testing.

On the last book read by the tester, I collected together a bunch of books, which I found helpful in the past.

19% have read some other book, 18% Lessons Learned in Software Testing, 18% Agile Testing, and 13% Perfect Software… and other illusions about testing. On the other answers, one thing struck me. There were some people pointing to books as Growing Object-Oriented Software Guided by Tests, and Working Effectively with Legacy Code, or Continuous Delivery. I don’t considered these as software testing books as to my understanding. I think this reflects the ambiguity that comes with the term software testing, but that could be just my interpretation.

Another thing struck me. 4% claimed they never have read a book on software testing.

On the book recommendations there were a few interesting points. At least two participants claimed that they read any of the ISTQB books last, and would not recommend any book on software testing. A lot of recommendations go out for Lessons Learned in Software Testing. Interesting in my data is also, that most of the participants who don’t recommend a book, have read books like any of the ISTQB books, The Art of Software Testing, or Managing the Testing Process.

When I try not to overrate the data, I would claim that we do not have the same understanding of what good testing consists of – given the variety of responses I got.

Some thoughts

On the programmer’s survey, I think my data is biased. I might have overestimated my reach with the survey here. I am quite sure that these data don’t reflect the state of our software development craft.

On the tester’s survey, I think my data is also biased. People reading my blog might actually be influenced by similar sources as I am. This means the context-driven and the Agile testing world. That’s ok, but I hoped for a variety of responses here as well. I seem to have got such responses by accident, but would like to see more people filling out this form to gain more insights, maybe.

That’s it for now. I hope to get some more responses, but don’t put too much faith into it.

In short, Angelique reminds us to ask potential new employees for the development processes they used, their development practices, – particularly TDD, pair programming, short iterations, and continuous integration – and how they educated themselves and kept their claws sharp. She also points out that she would ask for a proof of their talent, how they estimated, how deadlines are met, and what they can say about the costs involved when developing software.

This list was so compelling to that I decided to put up a similar list with the things I was looking out for hiring a software tester. I believe there are some unique skills I would look for in a software tester that I would not necessarily look for in a programmer. So, here it is.

I would ask about their approach in different contexts. Agile software development is all around us. But still many companies also use more traditional approaches. In the end, one approach to testing might work in an Agile shop, while it would fail dramatically on a more traditional project. I would look for their adaptability to different contexts, and how they react to different situations. In today’s world it’s certainly not enough to know about the latest methodology, but also to apply different techniques as unique situations unfold. I would also look out for their tactics in fast-paced Agile iterations, and how they adapt to two week long sprints. What about one week? What about daily deployments?

I would ask about the testing techniques they could show me right now without preparation. My experience in our field is that testers visit a course or two – if they actually can do so. After that they use the 20 percent of testing knowledge that they need in their day job – without exercising their brain cells on the remaining 80 percent. Even worse, there is little interest in growing beyond these practices. If the potential new hire can share a lot of testing techniques without preparation, she certainly uses all of these different techniques regularly.

I would ask about their programming experiences. Fast-paced iterations call for test automation. Even if you don’t work in an Agile context, programming knowledge will benefit you at creating different tools that assist your manual tests. In the end, you can talk to programmers on a different level, if you can at least read their code. Specifically I would ask the potential new tester if she could pair with me right now on some production code. I would also ask for experiences with TDD, pair programming, pair testing, continuous integration, and different automation tools and programming languages.

I would ask for heuristics they regularly use. Test automation alone is not enough. A good tester also needs to be aware of the oracles and heuristics by which we recognize a problem. A good tester also knows when to aim for more depth in their test sessions, or to aim for overview on a new product. These are covered in many of the mnemonics on software testing around. Maybe they even came up with their own mnemonic on aspects in their testing which they regularly use.

I would ask for a demonstration of their skills. This could mean to submit an example bug report as Lessons Learned in Software Testing points out. This certainly also means that I hand them some problem to test, and ask them to show me how they would test the particular application. Among the things I would look out for, is how they handle traps, and what basic assumptions about testing they follow through. I certainly would use one of the missions over at Testing Challenges.org. I would also spent an eye on how they try to clarify the mission, and how they involve the different stakeholders in their testing.

I would ask for how they work on their knowledge. What has been the latest book on software testing that they read? Which blogs do they read regularly? Did they invent a new testing technique (like the Black Viper testing)? Which conferences did they attend? Which online coaching opportunities did they take? Weekend Testing? Skype coaching? Miagi-Do? BBST? These are all examples of personal dedication to our craft. They also show a passion for life-long learning.

I would ask for how they collaborated. This includes collaboration with programmers like pair programming, but also with peers in pair testing sessions. I would also seek to get to know how they worked out specification details and acceptance tests with the customer. What is their approach to collaborate with programmers who don’t give a thing about testing and testers? How do they show their unique value they bring to the software development process, and how do they get others engaged in what they do? Testers need not be alone in their daily struggle on quality, and certainly shouldn’t be the gatekeeper about quality. I would look for a tester who understands that quality in the software is a team effort.

I would ask for their previous professional job. In the last year, I attended the second writing-about-testing workshop. During the introduction on the first day, everyone stated how she or he came into testing. Most of the participants didn’t pick software testing as their first job. Eventually they found out about their passion for testing by accident. Since then I made it a habit to interview testers about their path to the profession. Most of them had interesting stories to tell, and even compelling insights about fields of expertise that suits any tester.

Product:
Regression Test Calculator

Mission:
Test the regression test calculator for any flaws you can find. You might gain bonus points, if you can find out how the calculation is done. Another set of bonus points if you can come up with a better approach.

In the meantime I found out that Ajay Balamurugadas actually found the link to the website, and sent it to James and Michael. I think he deserves some special kudos for this.

These are the responses I received.

Twitter

I recevied some feedback over twitter. Tim Western challenged the purpose of the tool completely. He was not alone with this opinion. Justin Rohrman, and Ben Simo felt the same about the tool.

Michael Bolton noticed that “boundary” was mispelled in a link to another tool.

Peter H-L pointed out that you can actually get minus coverage. I wonder what minus coverage should mean. Maybe having tested a product less than untested at all.

jss mentioned that I should try one test case that takes one tester two hours. Two testers can execute this test in one hour. I think that calculator didn’t know about Brooks’ Law very well. Or the calculator also thinks that carrying out a baby takes two women 4.5 months.

Blog comments

I recevied four blog comments from my readers. One was actually a pingback from Rasmus Koorits who submitted his report via email. I will get to this in the next section.

Phil Kirkham played a bit with the calculator, but lost interest after getting the first division by zero error.

Jean-Paul Varwijk submitted his report on playing for fifteen minutes with the calculator. He found some interesting problems in just 15 minutes. I asked him for a condensed report. I hope he will reply on that.

Emile Zwiggelaar also went for a 15 minute session, and also found some interesting problems.

For all three reports, go back to the original blog entry, and read their comments. They found some quite interesting stuff.

E-Mail

I received exactly one report by email. It came from Rasmus Koorits, as I mentioned earlier. He had seven pages full of interesting stuff that he found. The report is very thorough. He showed great passion in the craft. I don’t dare to put his report up here without having asked him beforehand. Maybe I will add this later. I think he deserves the most kudos for following up, and he did well on that.

Some endnotes

I intentionally didn’t mention too much details about the bugs and problems. I hope that some readers will later dive into the topic, and submit a report on their own.

Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.

From time to time to I will publish some of the results. I aim for end of January for the first set of data.

Complexity Thinking

Complexity Thinking evolves around three main concepts. That is, in each self-organizing there are several containers which determine the boundaries of smaller groups. Every organizational hierarchy could be thought of as such a container. But there are also others. In a matrix organization, containers also evolve around the project structures. Testers and programmers are also two different containers.

Containers themselves are defined by significant differences to other containers. There are also insignificant different between containers, and within containers themselves. Complexity Thinking states that the significant ones are meaningful for the work as a change agent.

The third concept has to do with exchanges. In order to self-organize, people in the system have to exchange their differences between each other. If there are too few exchanges, then the team will not be able to self-organize. The things we strive for as change artists are transformational exchanges, exchanges that yield a different behavior, a transformation.

As a change agent for self-organization this model helps us to find the right balance between containers, significant differences, and transformational exchanges. If people are stuck because they lack information from another department, organize an exchange between the two. If people self-organization is limited because the containers are not clear, then you shape these, or shape them differently.

MOI(J) model

The MOI(J) model consists of four aspects and two dimensions, on what leaders should take into account. The letters mean motivation, organization, information, and jiggle. The dimensions consist of observation and action.

In any group of people as a leader you can observe their motivation, how they are organized, and how information flows within the group, and beyond the boundaries. You can also observe whether the team is stuck in some particular sense.

Then you have different options to help the team, and lead them. You can change their motivation by introducing competition or by raising incentives. You can change their organization by promoting one of the team members. You can change their information flow by bringing in a colleague from that other department. Sometimes you can also jiggle the team, and show them new ways to handle the situation.

Now, complexity thinking appears to me to be a subset of the MOI(J) model. Transformational exchanges are changes that I may bring when I change their information flow. Significant differences can be mostly found in the way the team organizes their work, and what motivates them. Only the concept of containers is a bit vague for me in the MOI(J) model. It could have something to do with jiggling those boundaries once the team gets stuck. Yet, I found the MOI(J) model goes pretty beyond the Complexity Thinking model since it considers more variables for me as a system change agent.

I think there is more to it. So, here is your mission, if you dare to accept it.

Product:
Regression Test Calculator

Mission:
Test the regression test calculator for any flaws you can find. You might gain bonus points, if you can find out how the calculation is done. Another set of bonus points if you can come up with a better approach.

I am sure, I do not exceed the number of books that for example Michael Larsen read this year, but I was still amazed about the number – having estimated it at about ten or twelve. I decided to visit back the books I read, and see which lessons stayed current even after having read them. This list is based upon my notes over at Library Thing, where I looked up which books I finished this year. Some of them I started back in 2010. Some of them are also in German. some have an English translation, others don’t. Maybe time learning some German for some of my readers. :)

Training From the Back of the Room! – Sharon L. Bowman

I made this an expedite in my reading list. My colleague Stefan Roock visited the course back in 2010, and reported great things from it. I started to read this book back in January, read through in one week, and immediately started to incorporate the lessons into my training. I received some new inspiration from Sharon back in November when I visited her course as well. Great book, great insights, a must-read for any trainer and workshop moderator.

How to Read a Book – Mortime J. Adler, Charles Van Doren

I started to read this back in 2010. I got inspired by it on how I could test better. Initially this was a recommendation from Ilja Preuss with whom I exchanged some e-mails back before my time at it-agile – and also his. It explains why you shouldn’t bother reading every book, because some of them are not worthwhile to read cover to cover. This is especially the case when you face a book that is written badly, or that has some beginners content which you are already familiar with. The book also explains how to find out about it. Recently I worked through my to read list, and prioritized the 30 or so to read books based on the recommendations from this book. While the title might be confusing, definitely a book worth reading – maybe not cover to cover, but that’s how I did it.

Please Understand Me II – David Kirsey

Having dug deeper in the first part of this series, I was wondering what I would face when starting this one. This is also a relict from 2010. I enjoyed the insights about the Myers-Briggs Type Indicator from this book, but also the different temperaments which you may find in the different SP, SJ, NT and NF preferences. I learned some new stuff which I also incorporated in my trainings on a meta-level. For example, I remember one training where I was facing a detailed-oriented S-preference and knew based on this book what I had to do. Today, I might question the lesson I tried back then, but it helped in this particular situation. If you’re unsure about other people surrounding you, you should probably read one of these – but be prepared that this is a psychology book. I had no problem with that, since I had educational science back in school with a psychology teacher. But you might find it dry to read.

Kanban – David J. Anderson

This is another expedite book in my reading list for 2011. I decided to jump deeper into the topic of Kanban back in February. My colleagues were discussing how to extend our knowledge about Kanban and our ability to coach companies adopting Kanban. I felt I had to dig deeper. I found this book interesting to read, but at times the lessons felt a bit too managerial. Being a tester that is suspicious about any metrics, I also had problems reading this part. I think Kanban is an interesting method, and it surely will evolve over the course of the next years even more.

Exploring Requirements – Quality before Design – Don C. Gause, Gerald M. Weinberg

Since I read Bridging the Communication Gap back in 2009 I had this on my book shelf. Finally I got to read this book. I enjoyed it. Especially I enjoyed reading about different requirements elicitation techniques, as well as the Mary Had a Little Lamb Heuristic. I applied it from time to time on some particular pieces on my blog – which readers thought to be a bit nitpicking. Unfortunately I was already aware of most of the lessons. Yet the authors achieved to teach me some new things as well.

Weinberg on Writing – The Fieldstone Method – Gerald M. Weinberg

A book on writing by an author that has written more than 50 technology books in the past 50 years. This was an awesome read. Since I am working on some pieces of writing myself, Jerry could give me some great hints on what to try out, and how to digest ideas. I also watched two different Alive in Wonderland movies as a result of reading this book. Great tips from a book writing guru.

Pömpel, Patt und Pillepoppen – Matthias E. Borner

This is a book on the German dialect as it is used in the region of Bielefeld – the place where I grew up and studied. It is covered with some stories about Bielefeld, a small city with a 300k population. I enjoyed diving out of the usual readings in English, and reading some humor back at that time.

Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity – David Sibbet

Back in February we organized a Visual Facilitation course in our company. I finally learned how to draw flipcharts nicely, and what to do to make them colorful and engaging. As a result, I ordered several books on visual facilitation afterwards. This is the first one I started to read. Oh dear, I have to train my flipchart skills some more. Recently I found out that I still have to work more on them. Maybe a resolution for 2012.

Behind Closed Doors: Secrets of Great Management – Johanna Rothman, Esther Derby

Before attending the Problem-solving leadership course back in May, I already had this book. I asked both Johanna and Esther to sign it for me back in Albuquerque, NM. I enjoyed the management story alongside the explanations about good management. It’s not a business novel alone. It’s a business novel aided with theoretical insights about management. I think I read this in two maybe three weeks, which is quite fast for me. And you really had to force me to turn this down.

Pömpel, Patt und Pillepoppen 2 – Matthias E. Borner

The second volume from the Bielefeld dialect. This is the volume where I ran into the following saying for the first time:

Bielefeld is the nicest city in the world. Everyone who says other lies – or has been somewhere else.

Having been somewhere else, I think the author is right about it. :)

Rethinking Systems Analysis and Design – Gerald M. Weinberg

I enjoyed reading this book on system analysis and design. In one of the first few chapters, Jerry claims that you will think differently about design once you finish this book. He was right about it. He raises many questions about what we call software design, and really makes you think about it differently by doing so. A must read for any wannabe designer. I think Design Thinking could be originated based on this book.

xkcd – Volume 0 – Randall Munroe

This is an awesome geek comic on the web. I had to read the book once I saw it came out. It covers many comics based on science, geek-wisdom, and other stuff. A must read for geeks.

Give and Take – Chester L. Karrass

This was a recommendation from Jerry Weinberg at PSL to me. At dinner I joined Esther Derby and Jerry Weinberg for some personal coaching. On our way back to the hotel, we discussed the issue of the psychological contracts. Jerry recommended this book to me. I enjoyed reading it, and it cleared up my mind for things I can do to set expectations about my work more clearly, and how to work with concessions. At times I found the structure a bit unnatural, but as a lookup reference it’s awesome.

5 Very Good Reasons to Punch a Dolphin in the Mouth (And Other Useful Guides) – Matthew Inman

This is the first Oatmeal book. Another one in the series of the comics I enjoy reading. Humorous at times, thought-provoking at other times.

Runtime Error: Not Invented Here Book 1 – Bill Barnes, Paul Southworth

Another web comic I read regularly. This one covers the first few episodes of the Not Invented Here comic. A strip on a software development comic which seems dysfunctional at times.

The Gift of Time – Fiona Charles (ed.)

This was a gift – both for me as well as for Jerry Weinberg. Back in 2010 I asked Michael Bolton whether he had written any book, as I wanted to get a sign from him on one of his pieces. He said, there was a chapter from him in this book. I couldn’t find a copy, so he brought it to me when we met for the first time at the Agile Testing Days in Berlin. The book is a gift for Jerry Weinberg’s 75th birthday in 2008. It covers a lot of stories about his life, his courses on PSL and the SHAPE forums, and how he helped to gain the testing profession more momentum. It’s a must read for any self-claimed student of Jerry.

Agile in a Flash: Speed-Learning Agile Software Development – Jeff Langer, Tim Ottinger und Susannah Pfalzer

This is not necessarily a book, but a set of cards. Each card has one aspect of Agile software development on it. It gave me some insights, and re-taught things I already had forgotten. I had the urge to introduce it to a client of mine for lunch and learn events. It worked to some degree. Since then I am reconsidering how to use it with clients. I think it’s awesome, but might be too dense for Agile beginners.

Computer Programming Fundamentals – Herbert D. Leeds, Gerald M. Weinberg

This book is 50 years old. Yet, I found it interesting to read about things that still hold true in the first few chapters. The book seems outdated at times, but it covers the field of software testing for the first time in our industry. After reading James Bach’s chapter in the Gift of Time, I had to dive into this book. I was glad to find a used copy, as you can’t buy a new copy of it. While the technology seems a bit outdated, the psychological insights about programming are still up-to-date. If this doesn’t scare you, then maybe one of these quotes I noted down while reading it:

All good rules should not be applied with unthinking faith.

One of the more dangerous occupational hazards in computing is the habit of working out a set of diagrams, formulas, and figures until some impressive statement like “twice as efficient” emerges.

If we produce a new vocabulary word (subroutine) we must not produce something sloppy or something that may be misunderstood or misinterpreted.

Knowledge of only the instructions on a computer will permit one to code; but to be a programmer of any professional standing, computer operation must be understood.

Facilitating Organization Change: Lessons From Complexity Science – Edwin E. Olson, Glenda Eyowang

When Diana Larsen visited us back in July, she spoke about a program called Human Systems Dynamics. One of my colleagues, Jens Coldewey immediately booked this certification course as well. I decided to first dive into the topic some more before coming up with a decision about it. This book covers some aspects of complexity thinking. It states that uncertainty is fine in self-organized systems, that you can work with containers, differences, and exchanges to bring in organizational change. The model seems to have some power. Currently I am working on getting the pieces from PSL together with this model from Complexity Thinking. I hope to get my thoughts down soon on it.

Ten Years of Userfriendly.Org – Illiad D. Frazer

I think userfriendly was the first comic I read online. This book covers ten years of it – nearly completely. It’s a pity that Illiad had to turn to different priorities recently. I don’t know when I started reading this book. It must have been back in 2009. I finally read through all the comics. It’s thick, heavy, and I liked it a lot.

Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten – Holger Koschek

This is a little novel on Scrum. My first thoughts were that this book started a bit too slow for me. Over time I enjoyed the tiny tale about the land of scrum where unicorns use Scrum for any project. You join a dragon trap team which uses Scrum to build a flexible dragon trap. Along the way the unicorn – the Scrum coach – explains some insights about Scrum to you. An awesome story, a nice book, unfortunately just available in German. The Power of Scrum could be an alternative for business people, but this is one goes deeper on the topic.

Die menschliche Seite des Projekterfolgs: Was Softwerker über (verborgene) Denkautomatismen und -modelle in der Projektarbeit wissen müssen – Peter Siwon

Another “only German” book. I think this is a must read for any German speaking student of Jerry Weinberg. It explains some of the things that we encounter in projects in a way that was easily accessible for me. It is nicely structured for an NT-type like myself, but might be too mechanic for an NF one. It covers the human side of project success as the title claims. The author digs really deep into the material, and tells a lot of stories about his studies of projects from about twenty years. A great read, but I think it’s a bit biased towards the German culture – which is why it’s ok to have it not translated, maybe. :)

Dilbert 2.0: 20 Years of Dilbert – Scott Adams

A selection of 20 years of Dilbert comics. Being comic fanatic, I enjoyed the insights about comic author life here. Adams describes how he got started as a comic writer, and how Dilbert took off. In Weinberg on Writing, Jerry writes that Scott Adams and Jerry had the same inspiration for some of their stories. Jerry for his writing, Adams for Dilbert. I love both of their styles.

Hope I could bring you some inspirations. I don’t mind about the count. If you would like to read more about my insights from different books, please drop me a line, and I might publish them more often in 2012.

We had about 12 participants in the dojo. After explaining some pieces about the format and the kata, we started the dojo. As the kata started, we had one participant asking questions up to the degree that the pair in front of the keyboard stopped doing anything.

Eventually we got the team back up to continue working on the problem. The claim of the interrupter was that we didn’t yet understand the problem well enough to design the solution. Another claim was that TDD was not a design technique. Let’s take a closer look at both of these.

We have to understand the problem before using TDD

You could argue that the Roman Numerals kata is not very complex. Yet it seems that it’s possible to not grasp the domain of the future code model. Let’s take a look on the problem.

The romans counted differently than we do now. They had letters for different numbers. “I” is 1, “V” is 5, “X” is 10. You combine two “I”s to yield a 2: “II”. You combine two tens to yield a twenty: “XX”. You combine five and three to yield an eight: “VIII”. There are two exceptions to this concatenation. The four and the nine are generated by subtracting one from five, respectively ten: “IV” and “IX”.

We started the kata with a test for one, then for two, then we were heading for three. The question was whether we should go for a test for four or five at that point. I recalled Kent Beck’s exercise at his advanced TDD course in November 2010. He had us performing a kata. Then he asked us performing the same kata, but working the tests in a different than the usual order. The thing is that once you have a final design in mind, you work towards it. Now, the situation in the dojo was differently, as we didn’t discuss a design.

Now, we were stuck at implementing a large construct of guard clauses. When we introduced the test for the five, then the test for the four, we finally made some progress. We had three instances of guard clauses that returned some value. All looked similar. We tried to see a different design when we were facing the situation with two similar blocks. The design we worked towards at that point seemed to get in our way once we introduced the four.

The case when we had three distinct blocks was easier, and led to a better design. Now, the question is, if I do not have a particular design in mind, can I still explore possible designs?

I think so. The thing is, that I have to stop thinking while refactoring. I have to start thinking again when I stop refactoring to see whether the design I’m heading towards is any good at all. Using continuous integration, I can then revert back to the old design, and go a little bit further.

TDD is not a design technique

This insight is mostly triggered by the realization that Exploratory Testing is not a test technique, but a test approach. This means that you can combine Exploratory Testing with any testing technique. It’s orthogonal to testing techniques.

Similarly, TDD is not a design technique. It does not solve the problem of designing the source code for you. It helps you to think about the design though. You can combine TDD with any other design technique like UML, prototyping, and whatever you can think of. TDD is an approach to design. It helps you finding a design in your source code, rather than designing it. It’s you that designs the source code.

I’d be interested in your thoughts on it in the comments.

I was too lazy in the last entry to upload an update of the mindmap I created. In order to head for the final testing where I get together all the loose ends, I need to consider it, though. Here is the latest mindmap after the fourth part.

I was planning to go for the timing, and take a closer look on the inner parts. Let’s start with timing – just in case I can’t figure how to assemble the tiles after tearing them apart. Yesterday I found out that my old stop watch from my swim trainer time was out of batteries. So I had to use my iPhone. This means that it will have less precision as I could have with a stop watch.

For game 1 I measured a total time of one minute fifteen seconds when you don’t do anything.

The manual claims that it adds five more seconds each time you find a five letter word. I validated that with one five letter word. Sorry, didn’t take the time for the randomness to work for my advantage and validate it with two or three five letter words.

I went next to game 2. While trying to do so, I could reproduce the bug from my first actual test session. I decided to investigate it a bit more. It turns out that while you see the summary from the previous game, and press the button on the tiles with the 1, 2, or 3 on it, you might get into another game of the previous game. Timing is crucial here. If you press the button just when the summary will be displayed again, you can find yourself in the previous game despite the game you intended to choose. This seems to happen more frequently when your batteries got lower and lower on power, as the reaction time of the tile increases dramatically. I reproduced this also with the change from game 2 to game 1 while digging deeper. I also raised my priority for different lightning conditions, maybe even in combination with lower battery power. But this won’t be part of my current mission.

Really jumping to game 2 I measured one minute thirty seconds for the initial round.

When you re-arrange and re-arrange more and more five letter word, your time will decrease. In between I measured roughly one minute.

I didn’t go deeper in the differences between each round like I did for game 3. This was mainly caused by a problem I noticed. I had just re-arranged a five letter word, just before time was up. Then the timer started to tick down, the tiles blinked to indicate I formed a correct word, and the game was over. This seems to indicate that I got one minute thirty overall, rather than having some time for each five letter word. The manual does not state it like that. I was a bit confused, but noted this thing for a future session, maybe.

For game 3 I could reproduce my timings from yesterday. That is you get roughly 20 seconds for the first word, then it decreases by roughly one second each round. Nothing interesting.

Now, on to the next part. I was really curious about disassembling the tiles – finally some destruction. I was also curious whether I could reprogram the tiles. There was a German version of the game, so there must be something like that. Also, for game 1 it seemed to have some memory about the words you already formed. So, how does one tile look from the insight? Oh, one final thought before going for destruction: What about children taking the toy in their mouth? Was it water-proof? Let’s see.

One piece of advice before we get started. I disassembled one piece unsure whether I will be able to re-assemble it afterwards. I did play around with electronic devices when I was younger, so I seemed a bit confident. Don’t try this at home for yourself, kids. You might either destruct your game, or burn your house down – maybe. :)

Now, let’s see. The manual states that I need a screw-driver to replace the batteries.

After opening the cover, I see two additional screws. So far there just seems to be the battery in there, nothing that really interests me. So, I continue to remove the two screws.

After tearing the tile into pieces, I see one main board, the button on the front has an additional plastic piece there, and I found two springs – unsure where they were originally placed.

I see four additional screws on the main board holding a cover for the display. It seems that there is some protection for the display so that little fingers won’t crush the LCD. I remove that one as well.

I start to explore the pieces I can recognize. The black pieces to the left and right from the display are the optical (I suppose) connectors to interact with the other four tiles. The board has some interesting stuff in there, but nothing I can recognize on my own. I can’t recognize a programmable interface here, and I don’t see memory, but I am quite certain that it’s too tiny for me to spot.

The connectors for the battery are not soldered with the board. I can remove them and place them back again. I really hope that I didn’t screw up the piece now. I’ll see.

I reassemble the tiles. The two springs seem to fit to the sound chip on the back panel. After putting all the screws back in, I try out the game, and still seems to work. Phew.

Tearing this piece apart didn’t reveal any new dramatically information to me. But I learned some bits about the tiles, and what safety functions the inventor put into place. It doesn’t seem to be water-proof. That’s maybe why it’s for ages eight and above.

Debriefing

So far, I have spent roughly two hours with the tiles. Another two hours for the write-ups. The game seems interesting, but also contains some inconsistencies. I saw one or two bugs there, one I couldn’t really reproduce. There is still some testing open for the tiles, but I’ll leave this to the ambitioned reader of my blog. I’d love to read about your approach if you do so.

The game seems to be ok for English speaking kids, but not so likely for foreign kids – even as an adult I had difficulties finding the words. If this is to provide a unique challenge for the game, it might be ok. The three different variants are also quite interesting, but in the long-run I don’t expect much curiosity about it. There is just one multiplayer game, that’s it. considering todays game consoles, kids might get bored pretty well. The tactile nature of the game, though, is a contrast to TV or computer games. For more multiplayer games, it would be interesting to combine two or three games to yield a bigger game with ten to fifteen letter words. Another dimension could be for kids to collect tiles, and yield more and more different variations. For example making explicit that you win one tile if you win the multiplayer game, then you could start collecting the pieces just as kids use to collect yugioh cards, or whatever is in fashion in your local area.

I hope you enjoyed this series. Looking forward to your thoughts and notes on it.