Markus Gärtner's Blog, page 10

Creating good testing challenges

Time and again I run into an ambitious tester that presents me his (or her) latest idea for a testing challenges. “What do you think about this situation where you set out the tester to learn X?” “You could provide product foo to the tester, and have him learn X. What do you think?” Time and again, I think there is something seriously flawed with this approach to create and design testing challenges.

Closed problems

What’s wrong with the examples that I showed? Let’s work through one together. I will think of a number, and you have to find out which one it is.

Ready, ok, let’s go.

No, it’s not 42.

It’s not 666.

It’s not NaN, that’s not a number.

No, it’s even not 31276391861.

You’re there yet? Starting to feel annoyed?

What’s the problem with such testing challenges? There is one true answer to the challenge. This is called a closed problem. Closed problems come with the drawback that there is one right answer, and you will get it quickly if you understand the underlying rules of the system – and you will become annoyed slowly like boiled frogs if you don’t.

Closed problems when given out as testing challenges to apprentices, junior testers, and so on, can come with this notion, there is one true answer. The problem with that is that these are not so much related to the work of testers. When we are working for a client, we are really rarely sent out to find that one bug that the developers hid in the software. Or those ten bugs. Or twenty. The real world usually has more to do with unforeseen problems that we discover. Rikard Edgren was the first to introduce me to the idea of serendipity, and how testers can make their environments work in favor of that.

Another problem with closed problems stems from one factor I consider crucial when it comes to learning. When giving out a testing challenge to someone, it should be something not so closely related to their work, and it should be obvious that they put some of the leisure time in it. That being said, the challenge should be fun to pursue rather than dragging out the energy from the student. The student should feel engaged to solve the puzzle. If there is one right answer and you just need to sort of “get it”, this usually becomes frustrating to most folks pretty quickly because they will feel trapped. Testing challenges should be fun.

Don’t get me wrong, there should be just the right amount of “kicking someone out of the comfort zone” that does not kick them out into the land of frustration. As psychologist Csíkszentmihályi found out, flow happens when the level of challenge meets the skill-level of the student, and does not put them off into the land of anxiety, or boredom. Personally, I can shift with a closed problem from frustration to boredom pretty soon, when I don’t “get it”.

Lessons from Weekend Testing

I remember some early lessons from my time when I co-facilitated a couple of sessions on Weekend Testing. I think it was Ajay who told us that the experimented with setting out traps for the attendees, but found out quickly that such kind of traps were simply not necessary. Testers were already up to creating their own traps.

My training experience tells me that giving out more open problems where there are several “right” solutions to solve the problem, are more demanding on the trainer. You need to design those exercises well for the learning objective. You also need to debrief the activity well enough to provide everyone involved the right amount of feedback so that they can learn and grow from the experience.

That’s what we mostly did during Weekend Testing sessions. While there was one hour of engaged testing in the beginning, testers took the biggest value out of the sessions from the debriefing part. And every trap you set out in the initial challenge usually fired back with ten traps testers set for themselves. At some point we realized that we simply didn’t need the up-front thinking, if testers could do that on their own.

Lessons from Experiential Learning

Ever since I attended PSL, I am aware that experiential learning is different. It goes deeper, and you learn from it whatever you need to take away in your current situation. The learning is context-dependent on the situation of the student.

There is a pitfall involved. If the student is feeling overwhelmed by the learning that you can offer, then he will have a hard time stepping back from the challenge. That said, students needs to be safe to step back from a challenge, and the challenger should be in the position to evaluate the thin line between leaving the comfort zone, and destroying the learning environment of the student.

Also, during the experience, testers should be in a position to play their role fully. They should be able to contribute like they always contribute. In the debriefing of the activity, though, the challenger needs to build the connection from the experience towards daily work.

That is what we somehow achieved in Weekend testing sessions. People were sent out for testing on their own, and we had a debrief afterwards. People that didn’t attend the one hour debriefing later usually were one-timers, while folks engaged in the second part, came back to learn more.

Open problems

What I took away from PSL in particular is that open problems are more fun to solve, and usually reflect the complex reality of our work situation in a better way. Therefore learning is more fun, and it comes with more direct take-aways for your next day at the office.

When designing testing challenges, we should avoid challenges that are too closed, and do not fit the current situation of the student that wants to learn something. If the experience is frustrating, he will not come back to learn more, and instead lose interest in us.

Testing challenges should be open, where we need to observe testers in a similar environment than their work situation, and help them make the connection back for their take-aways. In the end, that will be lots of more work for the challenger, but it will make the student grow more while having more fun.

Where I failed to lead

There is a lot to say about leadership. Personally, I consider it a skill that needs to be honed – and developed. There are lots of bosses in the companies out there that don’t have a clue about leadership – neither do I. I attended a couple of courses on leadership. It started off with a course called “From colleague to boss”, and I attended the Problem-solving Leadership course with Jerry Weinberg, Esther Derby, and Johanna Rothman. Most of them only made me aware about the things that I didn’t know, and the possible directions that I needed to learn more about. Let’s see where I have failed on leading dramatically in my past.

Empathy

The hardest lesson I ever learned was a few years back. I had been appointed a group leader position, took the training, and considered myself a good leader. I tried to listen to my colleagues since they knew where the action was. I knew we needed to change something. I was aware that I needed their help to derive a solution that was well understood. I also knew that I needed to align all of my group for the direction. Only then were we able to follow-up on the same path.

That’s why I included my colleagues into all of our discussions regarding the direction that we were going to follow.

In remember one lively discussion where I felt like I awakened from a terrible dream. “You are trying to direct us for your own opinion. You are playing the boss card.”

What?

I was totally unaware of that. What happened? I considered myself part of the solution. Therefore I considered myself part of the discussion, and wanted to be convinced. Seems that the outside impression in my colleagues was different. They thought I was trying to influence them based upon my appointed position, rather than trying to be on the same level as my colleagues.

I thought we were discussing on the same level, while my colleagues didn’t think so. Huh. I clearly lacked the empathy to understand that my colleagues saw me in a different position, and considered my weight in my arguments than I assumed. My outside perception didn’t match with my inside perception. That totally got me confused. Even worse, I failed to notice that my empathy filters shut me down from the imagination of that situation.

That stroke me.

What I learned from that situation is that from time to time, leaders need to slow down, and listen to the ones that are following them. With listening I mean actively listening rather than rushing to conclusions about what they perceive.

Partisanship

Another time, I was working a lot with one of my colleagues. Most of my team considered him the worst of us five. I wanted to make sure that he can follow along with the pace that the others were setting up.

I remember that we went out for lunch often, we talked a lot about work, family, and all that stuff. We discussed situations back at work, how to solve them, providing each other feedback, and thinking difficult situations ahead of time.

When I came back to propose all the awesome ideas that we could have ended up with, I noticed resistance. It took me some time to realize where this resistance came from, and it was partisanship.

Since I spent so much time with one of my colleagues, the other colleagues felt abandoned. Since we discussed lots of situations back at work, our thoughts even lost contact to their reality. They couldn’t understand how we derived at the point where we ended up at. That resulted in a disconnection between our proposal and their current struggles.

They had to resist our brilliant ideas since they couldn’t understand the problem that we were trying to solve. Even worse, they couldn’t imagine there was a problem – nor that that problem was the most important one to solve.

And it got worse. Since I talked on a more personal level with one of my colleagues, the others felt downgraded and abandoned. They were not only resisting our idea on the content level, but also on the personal level. That made the whole situation worse. In order to help them understand our points, I had to reach out to them on a personal level plus on the content level. That made experimenting worse, and dragged our innovation power down.

What I learned from that situation is that I shouldn’t take about work life when engaging with a colleague beyond work. That may ruin your whole team – especially if you are a leader.

Asynchronous communication

In other situations, I tried to make my colleagues aware that we had a problem. My personal introversion preferences, and my writing skill makes me write a lot in order to reflect, and make sense of all the various thoughts that jump up and down in my head.

I learned the hard way that writing emails, or blog entries is a terrible idea to create a sense of urgency.

Written communication lacks multiple feedback channels. What each of us writes down is ambiguous on multiple levels. When we engage with persons face to face then we broaden the feedback channels. There is lots of information that we take in during direct synchronous communication. It’s the gestures, the mimics, and we may ask clarifying questions. All these factors make direct face to face communication more effective and efficient than remote, asynchronous communication.

So, rather than creating a sense of urgency, or reaching anyone, I figured I created the opposite reaction. Everyone was fighting my ideas, close to no one was following up on the stuff that I had written down since no one could follow it. Everyone was thinking that I annoyed them, and I was the last to see that.

If you want to create a sense of urgency, make sure everyone can “listen” to your ideas, and ask clarifying questions. The best way I know of to make that happen is direct face to face communication.

Lessons learned

There are a couple of lessons I learned over the various years on leadership. If you want to lead people, either by being the appointed leader or the “natural leader”, you probably want to be aware of these different levels.

Before you try to “lead”, make sure how you are perceived by your colleagues. If your outside picture does not match your inside picture you might find out that there is a problem that no one will tell you about. Some people avoid the confrontation with their bosses. Get the delegation level for decisions clear.

Avoid personal friends. Everyone should have the feel that they have the same contribution to make. Avoid the trap where a colleague that you commute with often takes on too much influence. You will do a disservice to your other colleagues just because they live in a different part of the city, and can’t commute with you that often.

Finally, synchronous face to face communication trumps anything else when you try to create a sense of urgency. Things can get worse if you make the impression that you are giving out orders for your colleagues’ behavior just because they think you are the boss, and you have to follow up on your words. If they feel invited by direct communication, they will feel more invited to following you. As a leader it’s your job to be receptive for that kind of feedback – positive and negative.

More learning as a professional

This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:

In your blog post on learning, you’ve left out community, and bafflingly to me, practice.

Wholeheartedly I thanked him for the idea for today’s blog entry.

Practice

Seems I assumed too much in my last blog entry. I thought I made it obvious, but it seems that I missed to put practice into the blog entry on learning. Looking back, what I did in order to learn, was to dig deeply into theory, and directly apply it the next day. Here is an example.

At a certain point, I read about Computer Organization and Design. The authors Hennessy and Petterson explain many of the underlying concepts for today’s computer systems. They explain how a CPU works, how USB works, the mechanics of pipelining, memory allocation, and much more.

Being a math guy back in school, I paid particular attention to the chapters on converting numbers – and how mistakes could happen at different levels. Just about that time I was dealing with our system. There were two major components, one written in Java running on a JBoss application server, and the other written in C/C++. There was an XML interface between the two. The C/C++ component was the master of all currency related data, while the JBoss application stored all the business relevant data like customer data, and addresses and so on.

There were some pass through services in the JBoss application server that infected the balances in the system. This system was all about tariffs, prepaid, postpaid, and convergent billing. There were certain postpaid tariffs where a certain amount of money needed to be deducted based upon a monthly fee that needed to be paid. Unfortunately that amount could be pro-rated based upon the amount of days the account was active in the current month. Of course, the pro-rating changed based upon the amount of days per month as well. The interface between the Java component and the C/C++ component dealt with a percentage value in floating point notation.

I found a bug in that interface that was based upon usage of double precision floating point numbers rather than 128-bit floating point numbers as used by Double-typed variables in Java. That bug could lead to a miscalculation for large amounts monthly fees in certain months, because the conversion from binary to decimal digits in that case couldn’t carry along the right amount of fractional digits in the C/C++ component. The balances where calculated with six digits of precision.

I was only able to find that (maybe rare) bug, because I had understood the inner workings of binary and decimal maths. I was only able to find that bug because I dared to try out. I dared to practice this skill.

Practice is a key ingredient to incorporate lessons learned. I practiced when I read about LDAP, and I had to immediately try out stuff the next day at work. At times, I even couldn’t wait that long, and needed to give it a try right away. Thereby I was able to learn not only the theory of how it should work, and take that for granted. Instead I could play around with my inner concepts of how it should work, and how it really worked. There were many more things that I directly had to try out, and I consider practice a prevalent thing that professionals learn from. I even dare to state that you cannot learn without putting your knowledge to practice. That was my assumption yesterday. That’s why I left out the obvious.

Community

When it comes to community, I dare to state that communities weren’t my first learning source. If I recall correctly, it took up to reading Lessons Learned in Software Testing back in 2007, before I joined any mailing list. From then on, I dived deeper into mailing lists. Right now, I joined countless of them – and I muted lots of them. There are a couple mailing lists that I deliberately want to have a peek here and there – just to stay up-to-date.

But there’s more.

There are more and more online communities. Some of them meet up on Skype sessions, some on twitter, others in direct forums, like the Software Testing Club, or the AST forums. You can find lots of helpful folks there, and it only takes a few days to receive a helpful response in case you have a question (and present that you did the most basic research on your own rather than engaging in Let-Others-Work mentality).

Communities are a great resource for your learning. However, I found out later than my first course about this. It helped me shape in the long-run, and I didn’t need communities to get started. This might be about the time I was learning, and communities only grew later, but it might also be about me being unaware of those sources.

What about….?

I think there is more where you can go and learn from. But remember this: if you can directly apply stuff the next day back at work, your learning will stick deeper. Of course, you probably need to have the right amount of slack that play around with new ideas. You need personal freedom to master that new skill. If you don’t have it, then you probably need to invest some of your personal time.

Some folks claim that you need at least 10,000 hours of deliberate practice before reaching mastery for any skill. That might be true, and some folks claim that I invested a lot of my time in the early days. Might be that this time paid off in the long run. I joined this field in 2006. That is eight years ago. I am not so sure about where I currently ended up, whether it’s the right path, and whether my early pays off, or burns me out. Only time can tell that to me. Time will also tell you. Keep patient.

Learning as a professional

Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.

There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.

University

Personally, I have studied back from 1999 to 2005 in university. I learned a bunch of stuff. How to do programming in Haskell, how to program a 6-limbic robotic arm, and how to do offline and online training of computer systems. I learned about face detection algorithms, and we wrote one on our own. We adapted that stuff for office materials like a keyboard, a rubber band, and so on. My diploma thesis was about hand gesture detection applying similar approaches. I am still amazed that most smartphones nowadays can do the stuff we researched back then.

I interviewed for my first position in 2006. I was interviewed for a position of a software tester. I had heard about software testing twice in university. Once during a course on software engineering when it dealt with the V-model. There was a 15 minutes lecture on it. The other time was during the Software-Praktikum, a combination of programming, and some lectures. There was this professor who told us about those freaking folks doing extreme Programming. They were doing test-driven development. No one cold explain to us what it was in 2000.

So, I sat there the first few days into my new job, and needed to learn a bunch of stuff. Besides the unfamiliar domain, and the unfamiliar approaches to automatically executing tests on a Solaris machine, I needed to learn about software testing. That was my profession now.

I didn’t learn much about the domain I was working in back in university – no wonder. I slightly learned something about shell-scripting that I could use in my job. But I certainly didn’t learn anything about my profession – neither software testing, nor software development. So, I had to learn that somehow and somewhen differently.

Books

What I had learned in university about learning was to get a bunch of books on the topic, and get going. So, I ordered a book about software testing. It was a classic book, written in German. It had some decent amazon reviews, so I decided to get me a copy.

It was awful.

I couldn’t read it for longer than five minutes. All those terms didn’t give me a clue. It was worse. They were confusing me. Equivalence classes, white-box, black-box, you name it.

So, I still sat there, and couldn’t find out what to do. So, I took a different approach.

Peers

I started to ask questions to some of our senior testers. We were in the middle of a project, and were closing up on release 0.4 for an upcoming product. We had weekly meetings with our project manager that asked for status.

I had taken on some tests for use cases that I could understand two months into a new job. I was able to add customers, addresses, modify them, maybe I was able to create an account with those address data as well. That was it – mostly.

So, I took on some of the tasks related to customers, addresses, and maybe accounts. For me, those were easy. I merely created the tests that I felt were necessary. I worked with colleagues to have a look over my documents, and provide me feedback where I needed it.

I was able to learn from my colleagues back then more than I was able to learn from books, or rely on the knowledge that I had gained from university.

Training classes

One and a half year into my first job after university, I attended an in-house course on software testing from an outside consultancy. At that time, that guy spoke about all the stuff that was in the book that I had bought a couple of years ago on software testing.

At that time, I knew which test practices I would need. At that time, I didn’t see any benefits of the stuff that guy was offering. I never needed it again.

Due to lack of official training classes, I had decided to jump in and learn as much as I could to do a decent job on my own. I knew how to get to the sources that were relevant for my job. I had bought books which resonated with me, and were easy to read. The training class came to late, and it was merely justifying what I already knew.

Professionalism

What I had learned back in university was how to learn. University didn’t teach me lots of stuff that I would use again when I joined the corporate live, and worked for The Man. I had to re-invent my knowledge to fit the job that I was hired for. I knew how to do that thanks to university.

The training class that I attended eventually came too late. At that point I already had done a decent job as a tester, and was asked whether I wanted to become a group leader for a particular testing group. I already had learned what I needed to learn to do a decent job of software testing. If I had waited for the training class to kick in, I would have provided a dis-service to my employer. I could learn that faster than that.

There are good and bad books out there. But how can you differentiate the two as a beginner? You can’t. I jumped to the first, and really got disappointed. I was lucky enough to be able to follow my passion and my instincts, and could compensate a lot of missing knowledge by that. Over the years, I have read several testing related books. Now I think that I merely started with one of the worst ones. Bad luck. Maybe I should have looked for more alternatives first. Who knows. Peer recognition can be helpful with that.

But most of the stuff I needed to know I learned from my colleagues. They were able to help me on the job, and answer my most-pressuring questions. They were able to help me, to coach me, and to mentor me. They could help me with the pressing questions at the task I was given. They provided some answers to me, and eventually those helped me shape my mind.

Learning on the job with feedback from your peers is probably the biggest learning channel that you have access to. Use it whenever you can. Few other methods can provide you the same learning depth.

Scaling Agile – really?

There seems to be a buzz around scaling agile around lately. A couple of weeks ago I saw a tweet from Gabrielle Benefield that made me think.

Why is everyone hell bent on scaling Agile when they have trouble even getting one team going?

That question reminded me about a lesson I learned from Don Gause, and Jerry Weinberg in Are Your Lights On? What’s the problem? Who has the problem? And who should fix it? Let’s see.

What’s the problem?

A problem is the difference between a perceived state, and a desired state. In order to solve that problem, we may work on the state, the desire, or the perceiving. That’s the bottom line I got from the aforementioned book.

One question to ask in regards to the underlying problem folks try to solve when talking about scaling is what’s the problem they are trying to solve. Stick long enough with corporations, and some of the answers you receive for this are “we want to deliver faster”, “we want to deliver better quality”, and “we want to be more flexible”. These are all valid answers for the desired state.

As consultant, when entering a new client, one thing you try to find is has to do with the currently perceived state. The answer to that question lies in how good the client can currently perceive the situation. As an outside consultant you can often easily make the customer aware of some things he doesn’t see. That influences the perception of the current state in the organization. So to speak, as consultant us consultants help the organization perceive other things in their current reality, and thereby maybe shift their problem.

When it comes to agility, and the above quote from Gabrielle Benefield, the question probably should shift towards “are we really doing good in one team?”, “where are the problems with our current market situation?”, and “how can we deliver faster?” While trying to answer those questions, you might find out that you perceive your current situation differently, and scaling with 200 teams is not necessary, since 2 teams already can deliver lots of business functionality, while the other 198 teams can focus on conquering new markets.

What some of the fuzz around scaling agile right now is all about, is to shift the client’s perception regarding the desired state without challenging the perception of the current, and what causes some of the problems they are currently perceiving. I think rather than providing a solution to a perceived problem, or drawing a picture of a desired future state, we would be way better off helping the enterprises around to take a step back, and help them evaluate what they really want to do, and then solve that.

Who has the problem?

This already touches the field of who has the problem. When we talk about creating a desired state, my impression is that we try to impose a solution on all the large companies out there. I think that’s wrong because that focuses on the consultants having the problem of not being able to reach out to the large enterprises. So, all that a solution consisting of pre-defined practices solves lies in the utilization of the consultancy selling that solution.

In my current perception, that larger companies out there currently face that small startups can outperform them easily, and deliver better solutions more quickly. So, the one who really has the problem is the enterprise organization that is going to become extinct unless it changes something.

When talking about agility, and business agility in special, we should help those larger corporations to the agility that helps them outperform the competition. That probably means that we should engage with our clients, see their reality, and help them either shift their perceptions, or help them to really solve the problem.

Who should fix it?

You may have noticed I already shifted into this question a bit in the past sections. So, let’s focus on who should fix the problem of too few business agility, being too slow on the market, and so on.

What I perceive happening right now is this: a consultancy has invested large amounts of money in becoming certified for a particular method. They enter a new client, and sell that solution to them – because of sunken costs for their investment, and maybe because that’s the only thing they know.

That would mean that we really try to impose a solution on the client that has the problem.

With large organizations, as an outside consultant, I learned that I have limited influence on the folks. I don’t have budget responsibility for all the people involved. I don’t have payment influence for individual people. The only thing I can do lies in a servant leader role. I can help influence some people, but I can’t really put pressure on them – and that’s good.

Who’s the one that can effectively re-shape the current organization? Who’s the one that can effectively change team structures in the organization? Who’s the one that can create new teams from the existing structure? Usually it’s not the consultant that can directly do that, but the manager of the organization.

When introducing a new methodology, we shouldn’t rely too heavily on the solutions that outside consultants provide to us with their blueprints, practices, and direct actions. Rather us consultants should clarify how much we and the client will be able to agree, and have a 50:50 influence on the proposed solutions. I don’t see that the ivory tower blueprint solutions that consultants come up with will work out if we don’t make sure to connect with the ones that really have an influence on the organizational structure. And I think that they also shouldn’t delegate all their hard-earned influence onto us, the folks that have the fewest clue about the inner working of the organization at hand. We should do this together.

More Honest

When it comes to scaling agile, I think we should be more honest when helping others to implement a solution that should work for them. That includes understanding their reality, helping them see things they don’t see, and then help them to work on the resulting problems. When it comes to change management, there is still a bunch of stuff us agile consultant can work from change agents, and it’s better to join forces with our client rather than imposing our pre-fit solution, just because we thought about it. Thereby, we might eventually be able to help our clients – I hope that’s the problem that consultancies at large really try to solve.

Five years of fighting crappy code

Today marks the fifth anniversary of the Software Craftsmanship manifesto. Doug Bradbury asked me the following question:

Do you think that the bar of professionalism has been raised in the 5 years since the Software Craftsmanship Manifesto was published? Why or why not?

My short answer is “yes” – and “no”. Being around since the early days back in November 2008 when I joined the Software Craftsmanship mailing list, and having been involved in the different thoughts on the Ethics of Software Craftsmanship, my longer answer hides in this blog entry.

Where we raised the bar

Overall, I think we raised the bar to some extents. Here is a brief list of stuff I see attached to the Software Craftsmanship movement.

There are lots of conferences where we share our work. I was lucky enough to attend the first Software Craftsmanship conference in 2009 in London. It was a blast. Gladly, we didn’t stop there. Since then other conferences popped up, like the Software Craftsmanship conference North America, and the German Software Craftsmanship and Testing conference (SoCraTes), that also start to spread to the UK recently. It’s a very good thing that we keep on conferring, exchanging our thoughts, and sharing what we know to other peers in the field. Clearly a value that we put forth from the manifesto.

There are also a couple of books available on the topic. Uncle Bob Martin’s Clean Code and the lesser known Clean Coder to start with. Dave Hoover’s and Ade Oshineye’s Apprenticeship Patterns are lesser known. So is Sandro Mancuso’s Software Craftsmanship book. (I am guilty, I haven’t read it, yet, as well.) Not to forget Emily Bache’s excellent Coding Dojo Handbook. These books collect the Zeitgeist of our movement today. I hope to see more books coming up in the next years.

Then there are events like Code Retreats and Coding Dojos. Corey Haines popularized the former one; for the Dojos there are several people around that started them. These help persons of the craft of software development to learn more about coding practices in the 21st century. For example, I remember a code retreat where we had a couple of students attending. At the end of the day they thanked us all since they learned so much on this one day that their professor couldn’t have taught them in years of study at the university. Then there was this other guy that claimed that he would be looking for a new job on Monday – and he did. These events make people of the craft aware about more effective (and efficient) ways to program in this century, and how to overcome sacred beliefs about coding habits.

On a side note, I think that the same goes for the larger testing community out there. As I see it, the context-driven testing community is very close to both, the Agile and the Software Craftsmanship community. I get a lot out of all of the three communities, and I think that we could do better if we managed to join forces.

Last, I think the biggest impact the Software Craftsmanship movement came out of the very first SoCraTes conference. We got together, and thought “this can’t be it for another whole year; we need to maintain this momentum”. We created the German Softwerkskammer to spread the word about Software Craftsmanship. One year later, we found out, that we had started ten local user groups with this. Each group met between once per quarter up to several times per month. They shared their knowledge among each other. They helped convince the larger world of software developers out there, to do create well-crafted software by steadily adding value, and nurturing a community of professionals that understand how to create productive partnerships with their customers.

Where we lowered the bar

There are also things that trouble me, and I think we can do a bit better than that.

Early on, there was the Wandering book. I think it floated around between various craftspersons quite a lot. I think I was number 42 on the list when I signed up, and it took a year or so until the book made it to my hands. Unfortunately that book is – so is the revival book that I started about a year ago in Germany. It’s a pity, to some extent since if we can’t value our treasures, our words of wisdom to the extent that we put it aside, and forget to share our wisdom with the future generations of craftspersons sent out. If we do that with our words of wisdom so tragically, what do we expect our code bases to look like?

Recently Uncle Bob Martin had an answer to that question – and the community is heavily discussing it. The idea is the one of a dedicated foreman that has the right to reject certain changes to the version control system. I think – like all rules – we shouldn’t try to apply that rule without unthinking faith. Personally, I think we should answer the question “how does that help to advance the craft?” before we implement that foreman.

Then there is another thing that makes me worry. I have worked with a couple of companies in the past few years. In that, I saw a pattern emerging. There is this group of software craftsperson that think they are the elite. So they form their own central core team where the best code of all time is produced. This is pattern that is clearly not in line with the manifesto as I interpret it. As Software Craftspersons we should be able to share our tales, share our stories, share our practices. Creating an elite team that thinks they build the best code in the company is creating an artificial barrier that will prevent other folks from joining the elite club. It shuts down the sharing aspect that we held so dearly in the manifesto. Learn how to get along with your colleagues is the way to go.

How to move on?

As I see it, there are good aspects of software craftsmanship around – and there are bad ones. I would be surprised if craftsmanship was a silver bullet after all. I am glad that we could make more people aware of coding practices they never learned in the 19th century in university, and we are starting to reach out. From my perspective it’s still the tip of the iceberg, and if we don’t learn how to overcome some of our elitist thoughts, we are probably ending our history after five years. Let’s avoid that, and keep on fighting crappy code that we created.

The worst thing about electronic tools

A couple of weeks back, I became aware of a fact about electronic tools that gives a large drag to using it. I see lots of teams struggle with electronic tools. Most of the times these work with a raped bug-tracking tool used for – well, I think – status reporting towards their ScrumMaster during the daily Scrum meeting. That’s broken on so many levels – at least that’s what most team members reported to me when a particular tool was inflicted on them. The infliction usually happens either by sunken cost syndrome (“we invested XXXXX amount of money in that, you need to use it!”) or other self-imposed factors causes (“we work on twelve different planets”, “this paper thing is too touchy for me”, “we are green here, we don’t kill trees”). Let’s explore some of the reasons behind that, and try to come up with clues on why these are broken, and what I think the worst thing about these is.

Transparency

Empirical evidence trumps speculation – every single time. That is why Agile methodologies invest so much time in empirical process control. Empirical process control necessitates three key ingredients: inspection, adaptation, and transparency. You need to have transparency on your product, your process, and your current working plan on a daily basis in order to make the right decisions regarding the best actions to take next in order to inspect and adapt. If you don’t have transparency on the thing that you try to inspect, you will only receive a blurry picture, and can only improve that blurry picture. (And sometimes the best action to take is to unblur the situation.)

With electronic tools, the last thing that happens, is transparency. Usually during meetings – where transparency for inspect and adapt is most needed – there is one guy sitting in front of the mouse and keyboard, dominating the whole transparency by wildly scrolling and clicking around, or totally slowing progress of the meeting down to an unreasonable level by being the only typist in the meeting. I have rarely seen less effective ways to waste money.

On the bottom line, you get costs for installing, running, and maintaining the tool, time wasted in meetings by being less effective, and time wasted due to less transparency. Good job.

Plugins

I think the great invention of our age lies in – drum-roll – plugins! You can dynamically plug in behavior to every software today. Just as you could theme everything 15 years ago, now you can plug-in anything that you need to do. That’s why there are lots of plugins for the available electronic tools. I think at a point in the future we will need a plugin to manage our plugins more effectively.

What stroke me most a couple of weeks ago had to do with a tool where there was an “Agile plugin” promising that you could manage all your “Agile work” with it. It had an Agile backlog, it had an expedite lane, it even had Enterprise Java Gems!

Funny thing, I talked to the ScrumMaster and ProductOwner after a standup about the tool. They used the Kanban view for managing their bug tickets, and the Scrum view to have an insight into the current state of the Sprint. I asked why they kept on switching between the two views, and whether there wasn’t a combined one, so that they could easily see the amount of planned and unplanned work on one page. “That’s not possible.”

A couple of minutes later into that talk, I found out that another ProductOwner in the same room had created a dashboard to overcome that short-coming of the plugin on top of the tool that was really in place to track bugs. I mean

SERIOUSLY?

The whole transparency could be solved with the customized dashboard alltogether. I am quite sure that they wouldn’t need the plugin AT ALL. Thank you for providing that piece of junk, making everyone install it, getting confused about it, while never solving any real problem.

Filters

In the end, I noticed it boils down to this: filters. A year ago I worked with a team that used a tool that was heavily using filters to provide different insights into the product backlog, the sprint backlog, and the current state of the development.

The problem was that everyone had different filters. The bigger problem was that everyone had different technical filters in combination with their personal filters. So, everyone had a piece of truth on their mind whenever they entered a particular meeting. All of them together had totally different truths. Of course, all the meetings took a lot of effort to reach a common ground for all those different truths around.

We are all facing personal filters. For example, there are certain people that I will stop quickly listening to. Most of the time that effect has to do with personal history, personal experiences with folks, and at times also my coping-stance with the signs I see in a particular person – or maybe even just how likely that guy reminds about that dork back in my high-school years.

The same goes for various tools that we use on our computer. The problem comes from different filters that distort our reality. Every filter takes away some complexity so that we can more easily deal with the situation. There are personal filters that we develop over time, and there are technical ones that we use.

While working with an electronic tool, you have two filters while working with your teammates: the personal ones, and the electronic ones. When working with a physical board, you remove one set of filter that might distort your reality from the one of your colleague. Thereby you have an easier time to reach common understanding, and fewer opportunities that lead to shallow agreements.

The biggest problem

When it comes to electronic tools, I think the biggest problems arise from the various levels of filters involved that distort our truth from the truth of our colleagues. We should be sensible for it, and we should remove the tool whenever we notice problems with it. In the long run I never faced a situation where a physical tool was not better in bringing more transparency for a better inspect & adapt cycle, had fewer work-arounds to take (think plugins), and led more easily to a shared understanding of the situation. That’s why I think that electronic tools – despite the fact they were most often built for different needs – are ineffective, and therefore useless in a fast-paced environment.

Your mileage may vary.

Over-correction

When I became a swimming trainer, I had to learn various ways to teach kids how to improve their swimming strokes. As part of a seven weekend education course, we not only heard about stuff, but also had to give training lessons to our classmates that proved that we were eligible to the trainer certification. In these courses I learned about a gentle technique that I lately noticed to apply in other fields as well – whether appropriate or not.

OVer-correction in swimming

Say, you have a swimmer that is turning his whole body during crawl swimming when taking in breath. That’s terrible, since the swimmer will lose lots of momentum. He is rolling his body too far. The whole arm movements won’t be as effective as they could be in the water.

Another swimmer does not apply a wave movement on top of his body during breast-stroke. He will be losing momentum constantly, since his legs will slow him down way more than necessary. The same goes with the arms when he brings them back in the starting position.

What do you do as a trainer? You need to correct that movement. The easiest way that I learned was to over-correct the situation. In the first example, I would ask the swimmer to turn his head to a point at which he can barely take in air from above the waterline. I often asked kids to turn their heads just as high so that they could barely see the benches outside the water – but no higher. For the second example, I would incorporate a training lesson with various coordinative exercises. I would ask kids to swim a wave, then add the arms, then eventually add the legs – maybe with many more steps in between, depending on the particular group I was training with.

The technique is called over-correction. You over-compensate a wrong movement in the other direction for a limited amount of time. Then you go back to “normal” swimming, and the movement has shifted a bit. You do this over and over again to make a better movement stick.

I used this technique quite lots of times. Whenever I noticed there was something wrong, I planned in exercises for the training group that would correct some of the major errors. Notice that we also learned “movement sight” during the seven weekends. That is how to spot that something is wrong, to notice the wrong turn in the movement while observing the swimmer closely. Only when you directly see what goes wrong, you may provide corrective feedback after the swimmer finishes the lane. Or you can help the swimmer with exercises to over-correct. In either case, you need to spot the problem first, and then understand it well enough.

So, vision, feedback, and over-correction form a vital training package.

Over-correction in professional life

In software development I noticed the same technique applied by others. For example, take Michael Feathers’ book Working Effectively With Legacy Code. He provides a set of rules for unit tests in it:

A test is not a unit test if:

It talks to the database
It communicates across the network
It touches the file system
It can’t run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.

If you apply these rules without thinking, then you might start to wonder how you can test a class that is a network adapter for your application. Or how do you test the component that writes data to your disk, and will be used all over the place? A few years back, I asked Feathers, and he replied that he wrote down those rules at a time when developers would only test their code with integrated tests, rather than simple unit tests. He wanted to change that. (According to my experiences this is still the case.)

Clearly, he used over-correction to kick programmers out their comfort zone to think from a different perspective again.

Or take Lessons Learned in Software Testing. That one has a couple of contradicting lessons. For example, lesson 145 is titled “Use the IEEE Standard 829 for test documentation” while lessons 146 (the next one!) is titled “Don’t use the IEEE Standard 829″. That’s not to drive you crazy. It’s there to make you think. Think about your problem from a different perspective. It’s an over-correction – as I would call it.

An honest correction

As a trainer, coach, and consultant, I lately noticed that I use that technique a lot. Probably too much. When I say that programmers should start to test, I say that because I have made the best experiences with cross-training people in up- and down-stream activities.

At the local shop I once worked (for ten years), I knew how to do the cashier, I knew how to deal with vegetables, but my main activity was ordering of beverages, beer, wine, and liquor. I could contribute in other ways since I knew all this stuff, from product ordering, to the shipping process to how it is sold. I could jump in when there was trouble in any of these activities, and I could quickly evaluate the current situation, and jump in.

The same serves us in software development. If we know just enough to compensate for bottleneck situations, or when a colleague won the lottery and left the country for greener pastures, we are able to contribute more meaningfully.

In the past two weeks, I probably drew some false dichotomies. That was just to make you think. Of course, it might be the case that you need to develop some other skills like “movement sight” to spot a problem when it occurs, and the power of providing feedback in order for your colleagues to hear what you are trying to say. I will leave those ones for other blog entries.

SoCraTes 2014

I remember when Andreas Leidig approached me in late 2010. He wanted to get a discussion going regarding a conference on Software Craftsmanship in Germany. We decided to meet up during XP Days Germany in 2010, and see what we could do. We quickly agreed on an unconference format, two days, somewhere laid back. Some folks had organized the German Agile Coach Camp and Play4Agile in Rückersbach close to Frankfurt. We decided on that spot as well, and organized everything for 2011.

Early on, we decided that we will need outside support. That was when we started to reach out to other craftsmen, like Micah Martin, Adewale Oshineye, Sandro Mancuso, and many, many more. We had around 10-20 participants from outside Germany with us. All the tales they told us on how they were running things in London, Israel, Finland, you-name-it engaged us. It felt good to be around so many like-minded folks, and receive outside inspiration.

The first SoCraTes – Software Craftsmanship and Testing (un)conference – was a success. We had some track sessions back then, and a full day of Open Space. During the Open Space I joined a session that was looking for how to continue. With all the energy in the room, we placed ourselves on a virtual map of Germany. That was when I noticed, oh, there are a bunch of other folks around me that come from a similar location as I do. That was also when we decided that we needed to keep that spirit going.

One year later, we came back for SoCraTes 2012. Since the first conference we had founded 10 user groups all over Germany on Software Craftsmanship. There was one in Hamburg, one in Karlsruhe, one in Munich, one in Nürnberg, one in Berlin, one in Frankfurt, one in Dortmund, one in Düsseldorf, and one shared around Münster, Osnabrück, and Bielefeld. We created a timeline of events that had happened in the various local communities since our first get-together.

We were amazed about the various events, code retreats, user group meetings, and so on.

We still adhered to reserve space for foreign inspirations at that time. We had 10-20 people from outside Germany with us. However, Rückersbach had just 70 beds overall available. With ten local user groups potentially joining our unconference, we faced a serious problem. From each location just around 5 people would be able to join. So, with such a large community, we already excluded many potential attendees.

The format of the unconference had shifted. We had abandoned previously-set track sessions all-together. Instead we focused on two full days of Open Space. That provided the freedom necessary. Here’s the schedule from the two days in 2012.

At the end of the day, we decided to run the conference again in Rückersbach, but have it organized by a different group of people. We explicitly decided to pass over the organizing responsibility to one of the local groups from year to year.

Last year, the limited amount of beds became a problem. We discussed again what to do about it, and asked the organizers to seek a location that may scale up to 200 participants.

Rückersbach had an advantage: it was close to Frankfurt airport (about a one hour ride by car). That made it easy for people from other countries to attend, since Frankfurt is the largest airport in Germany. It would be hard to find such a spot with more beds in such a good position.

Late last year, the organizers contacted me. Since I am working in Hamburg, they asked me whether I could take a closer look at a potential spot for 2014 that sounded promising. They had 200 beds, and were located in Soltau. That’s about a one hour ride by car outside from Hamburg.

I agreed. When I finally made the trip there, I was amazed. The new hotel was awesome. There are ten meeting rooms all set up with video projectors, flipcharts, and so on, one central place where everyone meets, one large room for the Open Space opening, a bar with space for 170 people in the evening, a swimming pool, decent space outside close to nature. I got back to the organizers and told them that this spot would preserve the privacy that Rückersbach had with it, and that it seemed to be perfect to scale.

Now, I know that the announcement for SoCraTes 2014 is coming closer, and I can’t wait for the registration to open. Unfortunately I probably will only be able to attend on Friday, since I have a trip to the State to make for an AST board member meeting and CAST 2014 in the following week, but I know that I have to be there.

SoCraTes 2014 is scheduled for August 7th (evening arrival) to 9th, probably with a code retreat on Sunday, August 10th. I know it will be awesome. I know it will be full of craftsmanship, coding, and conferring. I know it will be worth my time. I now it will be worth the trip. You should reserve the date, too.

P.S.: Last week, I also heard rumors that the fine folks organizing SoCraTes 2014 are looking for sponsors. There will be different sponsor packages, some with free slots available. You can meet a bunch of fine folks there that are the top-notch in software development in Germany, Europe, and probably even the world. If you want to support the craft, please tell your bosses. It’s worth their money.

P.P.S.: Did you know that the UK folks – yeah, those that heavily influenced us in the first year – brought the same format to their country as well? I attended SoCraTes UK last year, and it was similarly awesome to the German event. They are organizing another event this year in June. Reserve the date as well.

The elite foreman

It turns out that Uncle Bob had some more to say on the role of the foreman, and how it applies in various situations. However, I have totally different experiences.

The foreman team

Over the past two to three years, I observed a pattern while visiting various clients in Germany, and I sense there is a correlation to what Uncle Bob is actually saying. Time and again, I see teams separating themselves from their peers. I see craftsmanship elite teams forming that put craftsmanship on their flag, rise it high – and dramatically fail to address the business needs underlying any software project.

More often than not these craftsmanship elite teams separate themselves at the core of the application, intending to create the best software they ever can. What teams outside that ideal bubble of crafts-fore-men get is that they are writing crappy code, but the world will be safe as long as that elite team continues to control all the commits to the main branch.

Sorry, I am exaggerating a tiny bit here. Just a tiny bit, unfortunately. These elite teams set themselves off to produce the best code that was created ever at this company – heck, ever in the whole damn universe.

This situation is so broken on so many levels.

First off, if you encapsulate yourself in your own little bubble, you are not teaching your peers – clearly a value that we set out five years ago when we discussed the contents of the craftsmanship manifesto, and the underlying ethics.

That sort of situation is also not very helpful for the larger community. It gives rise to a two-class organization. Either you are with or against us. Surely a driver for conflict, and Uncle Bob’s recent explanation carries along that this is what he intends to do.

A false dichotomy

Unfortunately, Uncle Bob is drawing a false dichotomy. Uncle Bob distinguishes between two extremes. On one hand, you have the perfect agile team that consists only of alpha-animal-like foremen that have a shared value system. On the other hand we have the open source model where a master committer appoints valuable contributors the right to also commit directly, and supervise the work of others.

This is a false dichotomy. There are many, many more levels of collaboration in between. There are many, many more levels of collaboration besides that. For example consider a quite senior programmer that is joining your team, but doesn’t know the code base. Would you grant him the commit rights from day one? Day ten? After ten successful commits?

Clearly, we can’t answer that question without more context. That context is crucial for deciding whether that new guy is actually sharing our value system, or parts of of it, or maybe just one of it. It’s hard to tell, isn’t it?

There are many more factors involved than meets the eye. There are more factors in play that don’t have anything to do with foremen at all, for example personal safety. These factors contribute largely to how productive and effective your team is. I worked on a team where we delivered nothing because the team hygiene wasn’t right. Overcoming that factor lead us to delivering twice the amount that we planned – for three sprints straight. Coincidence? I don’t think so.

A logical fallacy

Now, with all this said, here is the logical fallacy underlying Uncle Bob’s reasoning. He explains that someone might feel attracted to his classes. Then those folks join his classes, and ask him questions like “how can I convince my team mates?” Uncle Bob says that you can’t – I think you can, but it will take time.

The logical fallacy though, is this: Who is making you a foreman? Who is going to make you a natural leader that others want to follow?

Think about it. If you ask questions like “how do I convince my colleagues back at work?” you probably are not a natural leader. Otherwise your colleagues would follow you. Uncle Bob suggests to put those guys in the role of the foreman. But who would be doing that? Can you do it yourself?

I think this leads to elite thinking. “We are the elite. Please take a step aside if you’re not willing to join us.” On one hand, this might be good, since work might get done, and we will end up with better code than before. It resonates to some extent with me, since it sort of replicated the role of the ProductOwner for the code.

Still, it’s wrong. it’s wrong since you can’t lead without people following you. For that to happen you have to convince your colleagues for example by leading by example. That’s one way to do that.

I don’t know what Uncle Bob’s ultimate goal is with this rule and role. I am suspicious that it will in the end lead to sorting out capable from non-capable programmers and team members. I think it would be more helpful to engage in more proactive teaching with the ones that need it, and create a system that makes you aware when something is wrong. But maybe that’s just a cultural bias from my side.