Markus Gärtner's Blog, page 6

The Deliberate Tester – Chapter 3: Fallacies and Pitfalls

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. In case you want to catch up with the previous parts, I published these ones earlier:

Chapter 1: Session-based explorationChapter 2: Facing the Business with AutomationChapter 3: Fallacies and Pitfalls

Peter hardly slept when turning in the next day. He couldn’t wait to see the results of their tests on the nightly build. He got directly to John’s office.
“Do you have the results from the nightly build? Did everything run well?”
“Good morning, Junior. How are you?”
“Fine, now, what about…”
“Patience. Patience. I just arrived. Right after getting myself a coffee, we can take a closer look into the results.”
“Great.”
The test results from the nightly build looked all pleasing. John showed Peter the progress of the last few builds in a graphical overview. The number of test cases was slowly crawling upwards. Everything looked interesting.

“Ah, here he is. Peter, may I show you something? If you mind, John?”
“Ah, go on, Jennifer. Show the kid the application. We made some pretty good progress here yesterday.”
“Yeah, I saw the results from the nightly build and the automation. Come on, Peter, let’s explore just that build.”
Peter was surprised. He wanted to stay with the automation since it released him from many of the tedious steps in manual testing.
“Go ahead, Junior. You may come back after that session.”

“Alright, let’s set the charter for the next ninety minutes.”
“I would like to explore some of the areas we automated yesterday.”
“Alright, so, what’s our mission?”
Jennifer and Peter brainstormed about the features John and Peter automated just the day before. Peter tried to bring in many areas he would like to inspect, but Jennifer told him that ninety minutes of testing are rather short. So, they set up a minimal charter that both could agree upon. Then they started to explore the application. Jennifer had some tools prepared to quickly bring in the test data they would need.

“What’s this?” Peter asked.
“Looks suspicious to me, too. I think we got a bug here.”
“Awww, but the automated tests passed this build, didn’t they?”
“Yeah, you saw the results yourself, didn’t you?”
“But, … does this mean that our automation was useless?”
“No, but automation alone is seldomly enough. It helps us get rid of most of the tedious test cycles, but we need to inspect and explore the problem with a sapient mind in front of it to be certain about it.”
“So, let me note this down so that John and I can write an automated test for it later.”
“Hold on. Let’s first dig deeper into the problem. What happens, if I do this?”
Jennifer clicked a button and entered a different text into the user interface on the screen. The application crashed after printing a large portion of text on the console from which it got started.
“Now, that is interesting.”
“Why? I don’t understand.”
“Looks like there is a problem with our user interface. Seems like the layout is screwed. Does not look like something that should be automated.”
“How come?”
“You see, we have a screen here with many elements. These elements have internal identifiers. There are now two of these elements overlayed by each other. In order to write an automated test for it, you would need to identify the position of these elements in x- and y-coordinates and compare both elements against each other. We don’t have a way to automate these with a reasonable enough effort. Let’s write it down on our issue list. That GUI needs to be re-aligned properly for the next release. We’ll address it during debriefing.”
“Ok, that means I should throw away my note for the automation?”
“Well, we may discuss this during debriefing together with Eric and maybe also John. That’s why we make a note of it and go on. We have to weigh in costs of automation and benefits from it here.”
“Ah, I understand your point.”

Eric already expected Jennifer and Peter.
“So, what did you find? We were planning to ship tomorrow. May we still make it?”
“Well, we got one crash from a misaligned user interface.”
“Oh, let’s get in touch with the user interface developers directly. Does not sound too complicated, though a crash is dramatic.”
“Yeah. We’re directly going over to them after the debrief.”
“Peter, what did you learn from this session?”
“Well, two things. First of all, test automation may be fast, but it is merely enough. We still need to explore the product for such problems with the alignment of the user interface, usability testing, etc.”
“Great. So what’s the second lesson?”
“Second, not every test can be automated.”
“Not every?”
“Well, maybe we can automate nearly every test, but not with a reasonable amount of effort put into it. Of course, we may exercise some of those automated tests in 10 years, maybe in 20 years, but who would like to wait for a product for that long period of time?”
“Great, Peter. You’re absolutely right. I see you making great progress, already.”
“Well, thank you. I think I got great teachers.”

How to handle technical debt?

Over the years, I have seen many companies struggling with paying off technical debt and legacy code. Heck, I produced legacy code within a 45-minute session at a code retreat on my own, so consider me guilty as charged as well. Over the years, I have seen a pretty tiny fraction of companies actually managing their technical debt. So, here are a few stories that I oftentimes share from these companies and how they tackled technical debt and legacy code – with no claim for this to be a complete list of things that might work. Please add any additional advice you want to share in the comments.

The Boy Scout Rule

My go-to advice stems from the boy scout rule:

Leave the campgrounds cleaner than you found it.

In your team develop the attitude that whenever you implement something new, the pieces of code you touch will only be checked in afterward in a slightly cleaner state than you found it. Over time, the pieces of code that you touched regularly will end up cleaner, only leaving those pesky places that you rarely touch, if at all, in an unclean state.

Over time, you will end up in an ever slightly better position than the day or check-in before. At one point you will realize that the code base you’re working on, now became quite manageable, and can maybe move on. But please, keep the boy scout rule in place. Overwise technical debt will keep reappearing.

We established this rule on a team that I joined years back. They worked on an old Java code base, 10 to 15 years old with maybe 1 million lines of production code. There were zero automated tests when I joined the team in that year in August, and they had some features that needed to go live by the end of the year due to some changes in laws surrounding their business.

With every product backlog item we implemented, we considered adding automated, micro-level unit tests for the new lines of code that we wrote. Within a period of four months, we managed to reach a code coverage level of 10-15 percent, depending on the component of their system. By the end of the year, I noticed less defensive programming, and in most parts, just by the click of a button or by running the build script, we received feedback from the newly added unit tests on whether we broke something that had worked in the past. All of that enabled us to work more effectively with the code base, sometimes daring larger steps or more interesting re-designs of the existing code – and stepping back when unintentionally our unit tests told us seconds after a change that we broke something.

All of this was enabled by applying the boy scout rule and adding unit tests as we went ahead.

The Big Redesign in the sky

Of course, in that old code base, our efforts did not solve every problem. Over the years and decades, so much technical debt had accrued. I recall in the early years of software craftsmanship, I recall a blog entry from Uncle Bob Martin about the “Big Redesign in the sky”. Unfortunately, I’m unable to find a direct link to the original from back in the day. So, here’s the essence retold from my old brain’s memories.

A software system is so messed up in technical debt, that no programmer dares to make even the slightest change without cautious steps. Pretty soon, every programmer calls for a big redesign of the system, the company is eventually convinced to go ahead with writing the system anew and a tiger team is formed to tackle the new endeavor. Some programmers are left behind to maintain the old system while the elite tiger team writes a new system for some while. The tiger team tries to put in all the lessons learned, but the business gets more nervous and starts to ask for new features in the old system. The tiger team continues to work on the new system, being pressed to re-implement the old system, not daring to work on the new features in their new system, yet. Over time, many new functionalities get added to the old system that is not implemented in the new system. When the new system is finally rolled out – probably later than initially thought – the tiger team hands it over to the other developers that now need to put in the new functionality as well. Pretty soon, new calls for a redesign pop up restarting the cycle again.

In our case, after the first initial four months of me adding automated unit tests to features we developed anyways, the team was split into two teams: One team working on new functionalities, the other team working on refactoring the system. Both teams worked on the same subversion (yeah, I’m pretty old) branch. Whenever the refactoring team touched similar pieces of the code base where the other team added new functionality, they coordinated with each other. In that year with the split team, they managed to roll out 25 releases – every other week, in line with their 2-week Sprint cadence – to its 400 subsidiaries around the country. I oftentimes compare this situation to changing the tires of a car that is underway on a German highway at full speed.

Basically what they did was lay out the big redesign as a series of many refactoring steps. In this 10 to 15 years old code base, there were many questionable things. For example, early on they invested in offline functionality for the branch offices. Regularly they send over their daily tally information to the piece of the system that was running in its company headquarters. Since the branch offices did not have reliable internet connection all the time, early on they invested in hand-written offline functionality. Over time, more and more libraries added some kind of offline functionality so that now many lines of code could be replaced with the magic of some library. Of course, replacing the old code that was proven to work in 400 branch offices was risky, so they split up the refactoring of that piece of code into smaller, deliverable steps, that they could still ship at the end of every two-week Sprint.

Working in this way of course took longer for the whole redesign to eventually finish. I think it took more than 15 months in the end. Considering the alternative to work with the full force of all team members on the refactoring – say – for 4 months, and all the refactored system can do then, is basically the same as before, is not a valid option I have seen that many companies can dare to do. In this circumstance, they were heavily driven by changes in laws and regulatory changes that turned up two, maybe three months before they needed to be implemented in production. So, this was no valid option this company could use.

Of course, being able to split larger refactorings into a series of smaller ones that maintain the ability to still ship the product after each step, is a skill that many teams lack. This company was lucky to have experiences developers to pull this off. So, educating your developers about refactorings, and how larger refactorings are merely a series of smaller refactorings was something the developers in this company knew by heart.

Refactoring to patterns

In a story I shared recently, I surprised a self-proclaimed architect at a local coding dojo challenge. Basically, what I applied there, were the lessons I took from Joshua Kerievsky’s Refactoring to patterns book where he stressed the point I just raised. Combining Design Patterns and Refactorings to go from a Strategy pattern towards a class hierarchy and vice versa by applying multiple refactorings in a certain order, is a skill that not many developers have learned.

Basically learning the basics of our trade as software developers, not taking the first stack overflow solution for granted without understanding and rewriting it to fit your needs, is a habit, I continue to this day when working with code. I continue to be surprised, even years after such insightful books and articles have been written, that there are so many developers still convinced on how they can change the world without knowing some of the basics behind that.

Three basics

These are my three best advice when dealing with technical debt and legacy code:

honor the boy scout rulesplit up larger refactoring into smaller stepslearn to walk before you run

What is your best advice on technical debt and legacy code that you feel you have a war story to share about? Anything obvious that I missed along the way?

Remembering Jerry: Computer Programming Fundamentals

It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we are going to take a look at one of his earliest works I could get my hands on Computer Programming Fundamentals, co-authored with Herbert D. Leeds. published by McGraw-Hill in 1961.

[image error]

I recall this book going into much detail about computers. In these early days of the computer age, Leeds and Weinberg cover much of the foundation of most computers around even today. This book is not so much about leadership, or what any of the other Weinberg books cover that I read. Instead, you should feel comfortable reading about assembly language, and covering very low details in the computer field. I felt comfortable jumping into this book because I had read the great Write Great Code series beforehand, and having worked through Patterson and Hennessy years prior, I wanted to see what Jerry’s earlier writings were all about.

And I found myself surprised by some citations that I had to write immediately. No matter what year Jerry’s books were initially published, he has this writing style that is timeless. Sure, some of the assembly language details have not aged over the years, but still, I was able to find some timeless gems even in this decades-old book. Let’s go through the notes I kept while reading this book to remind me later about lessons from 1961. (Unfortunately, I did not note down the page number back then.)

All good rules should not be applied with unthinking faith.

The most prevalent thing I encounter regularly nowadays where I see a good rule applied with unthinking faith is probably the user story template. My favorite example where you can see the user story applied without thinking about it, probably is “As a line of code, I want another line of code, so that I’m not so lonely anymore.” I often point product owners and Scrum Masters to the fact that Ron Jeffries, the first XP coach who basically invented user stories talks about that template as training wheels. Turning on your brain, once you see something like that in your product backlog, you probably will also question whether that template is helpful in this circumstance at all.

Over the years, I have seen many such good rules applied with unthinking faith. Heck, I’m guilty as charged with doing that on my own. Reading a book from 1961 that I’m not the first to realize, gave me shivers, and some relief at the same time. Please keep your brain turned on while working. It will pay off in the longer run.

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.

Oh, I wasn’t aware that the S_Fe framework was already around in 1961. I surely felt like it was an ancient dinosaur when I crossed paths with it for the first time.

Jokes aside, I stand in awe at the wisdom behind this. You surely have come across this phenomenon in your career as well. Seeing that this pattern started actually WAY earlier, is both a relief and some kind of a shock to me. A relief that this is not as new as I thought it was. A shock that we never managed to overcome this in all these decades.

If we have mastered a few of these fundamentals along with the habit of curious exploration, we can rediscover special techniques as we need them.

Here, in this quote, I see the twelfth principle of the Agile Manifesto reflected. We should continue to learn new things curiously. By keeping our curiosity up, we will find new ways to approach problems and find clever solutions to ever-emerging problems. There are too many organizations I have seen over the years, that basically gave up on this curiosity, and I often leave these companies with the feeling that over time they will have to realize their demise if they don’t change that.

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

This quote immediately reminded me of the aspirations in Clean Code and the Software Craftsmanship movement that started from this. Of course, code is abstract and subject to interpretation. The less likely we manage to write our code, our unit tests, and our acceptance tests for misunderstanding and misinterpretation, the better off we will be. That was the case decades ago, and with more and more abstraction layers in higher-level programming added, this is a good reminder to avoid wasting time while trying to understand your code from yesterday.

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

In this quote, I am reminded of why I warn about the Year 10,000 problem already. In my mind, very few people will still understand how the underlying computer works and how dates are represented. Maybe two persons in the universe will understand that by then, and the computer age will long have forgotten the basics or fundamentals of the machine. If we stop to understand what the machines are doing, we will suffer the fate of being poor servants to the machines that should serve us. Maybe a story on my own is appropriate on this one.

A couple of years back, I had two TDD classes with a client on two different teams. Once was in the C++ programming language, the other for a team that used JavaScript. In the days before the training, I got familiar with the technology stack, especially since I never wrote much JavaScript code on my own. I programmed a kata or two in the evening to get myself ready to help with the most basic hurdles that the group in my training could face.

For JavaScript, whenever I ran into a problem stemming from my lack of understanding of the language, I looked on the internet for a solution to something. Oftentimes, I found a solution on StackOverflow, read through it, tried to understand it, then wrote my solution in my kata based on my new understanding of how the language works.

When visiting the JavaScript team, the youngest member on that team described himself as self-taught and programming JavaScript for six months. During the training, I joined him in the exercises and noticed how he searched on the internet for a solution to a particular problem, then directly copied & pasted the solution from StackOverflow without trying to understand it at all. Basically, six months in, he was still programming as I did the week prior. The only difference between him and me was, that I tried to understand what I was copying over. Leeds and Weinberg knew about this decades prior.

In a Twitter conversation years back, I recall Michael Bolton pointing out to me that these quotes are timeless since Computer Programming Fundamentals are, well, fundamental. I don’t recall more nuggets from this book, otherwise, I would have written them down. For me, I was delighted to see how Jerry over the years kept to his nature of writing timelessly, and that even started with this book from 1961. Generally, I wouldn’t recommend or urge you to read it, as some of the technical details might either shy you away or they have not stood the test of time that well. I read this book out of my own curiosity, and as you can hopefully see, I found some still pretty relevant quotes in there.

The Deliberate Tester – Chapter 2: Facing the Business with Automation

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Friday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. In case you want to catch up with the previous parts, I published these ones earlier:

Chapter 1: Session-based explorationChapter 2: Facing the Business with Automation

As Eric and Peter came into his office, John turned to them.
“Hi Eric and Peter. Eric, you wanted me to show our junior some test automation?”
“Exactly. He stayed the morning with Jennifer and was eager to see something more ‘interesting’.”
Eric and John laughed, Peter smirked sheepishly.
“Alright, give me two hours with him.”
John showed Peter a web-page which looked quite similar to the product he tested in the morning.
“On this user interface we write down what our automated tests shall exercise later on.”
Peter was amazed. “Did you build the product again with a testable user interface?”
“Sort of. We have some mechanisms to express expected values and exercise them in the system we’re testing. We just need to write it up in the right fashion. Later, we’ll automate these tiny pieces and bits to interact with the system.”
“Ok, I recognize this part of the system from my session with Jennifer this morning.”
John and Peter worked through the web interface. John answered Peter’s questions patiently. Peter suggested to incorporate some of the tests he had run together with Jennifer. John was delighted by the enthusiasm the junior spread out.

After John had shown Peter some of the tests in the web interface, he started to switch topics.
“Now, let’s move on to the automation part.”
He switched to another screen. Peter immediately recognized the IDE from his university courses. There was a green bar indicating that his unit tests passed.
“Ah, you ran the tests through the unit test runner.”
“No. They are run directly in the web interface.”
“But, … that green bar… that’s from a unit test run, isn’t it?”
“Yes, exactly.”
“So, you’re running the unit tests from your developers then?”
“Hahaha, no, these are the unit tests for our automation code.”
Peter struggled. “So, … you write unit tests… for your tests?”
“Yes, of course. For complex test classes, we write unit tests, so that we remind ourselves about our thoughts the next time our paths cross them.”
“So, you test your tests?”
“Yes, does this sound unusual to you?”
“Well, I don’t think there was a course mentioning this in university.”
“Yeah, true. We learned this the hard way. A few years earlier we tried to automate some of our tests. We bought a capture and replay tool, which was able to record your interactions on the screen, store them on the hard-drive and play them back later.”
“Oh, why don’t you use it any more? This sounds terrific.”
“Well, the automated scripts couldn’t keep up the pace with the development. Just move a button two pixels to the right, and boom, we were spending the weekend capturing the tests again, or just adapting them to the new UI layout.”
“Oh.”
“Exactly. Now, we automate our tests using a programming language. For the more complex classes we use test-driven development. Just as our developers. We evolve the functions. See, this test we wrote earlier. Let me exercise it.”
Back on the browser window John hit a button on the web interface and parts of the page got coloured yellow, red, and green.
“You see this yellow bit here? It indicates a missing functionality for the test automation. This one we’re going to develop now.”
He pointed to one of the new tables in a test that Peter came up with.
“Alright, but test-driven development? I heard about that, but never practiced it.”
“True, I assumed so. I propose we use Ping-Pong-Programming.”
“Ping-Pong-Programming? Where do I get my racket?”
“Hahaha, no, let’s write down some of the things our new class will be doing.”

John fetched a piece of paper from his desk. Peter was struggling.
“But, … you said we were programming.”
“Yes, but we need to think about what to program before starting to do so. Typing is not the bottleneck, otherwise we would simply get ourselves faster keyboards.”
“Ok, so, what do we note down on that paper?”
“We denote our charter for the class and the TDD session. We think up-front about what our little class here shall do and write it down as examples. These examples will then guide us through the implementation.”
“Ah, I start to understand, how about …”
Peter and John started to brainstorm about the functions they would like to see in the class.

“Now we have settled our charter. On to the fun part. Let me write down the first test here for you.”
John implemented a tiny piece of the unit test code, hit the test button, and the green bar turned red indicating a failing test. John passed on the keyboard to Peter.
“Now, your turn. Make the test green.”
“Ok, let me think. We need…”
“Ah, no, just make that tiny piece green. It does not need to do more. We’ll come to those parts later.”
Peter had a big question mark in his eyes.
“Just write down the simplest implementation you can think of that makes this test pass.”
“But, … that would be returning the expected value. Isn’t that cheating?”
“It would be cheating if we left it as is by then, but we aren’t going to do that.”
Peter slowly erased the code he had started with and filled in the return statement for the expected value. As the test turned green, John striked through the first item on their charter.
“Now, write a test for the second item on our list and handle the keyboard back to me, so I can turn it green.”
Peter did as he was told. John quickly implemented just what was needed to make the test turn green. Then he did something, which Peter had slightly heard of before: refactoring. John polished up the code, wrote the next test and handed back the keyboard to Peter.

After a few more keyboard exchanges, John and Peter had worked through the list. Peter felt unsure. The implementation part was more fun than work, and Ping-Pong-Programming seemed to be a great thing.
“Now, we should be able to exercise this test in the browser.” John hit the button on the web interface again, and this time the parts of the tables turned all green. “Ok, great. Let’s take a break.”
“So, that’s all about automation?”
“Yeah, exactly. Not quite what you expected, hm?”
“Yes, actually, it felt more like fun than like work.”
“Exactly this is why it works.”
After a short break John and Peter got back to the parts still missing in the automation code. At the end of the first afternoon, John started to execute all automated tests. When they saw them all passing, he checked in everything Peter and he had worked on.
“Now, it’s time to get home, kid. In the night these tests will be executed against the latest changes in the version control system. Tomorrow we should be able to see some progress then.”
“Ok, thank you. This whole afternoon passed in no time.”
“Before you head home, let’s sit together with Eric for a debriefing.”
“Alright.”

Eric was already awaiting Peter und John.
“So, how did the non-boring part turn out?”
“Oh, it was really great. Time passed quickly and I feel like we made a bunch of progress.”
“So, you wrote down some of the tables, and automated them?”
“Yeah, exactly. John showed me something called… erm, table tennis… no ping-pong programming. That was really great.”
“What else did you learn?”
“Tiny steps with quick feedback are crucial. We took tiny steps with automating the web-browser based tests, and took even finer steps with the unit-level tests. Having the quick feedback from the automated parts really helped.”
“Great. Tomorrow let’s see if your new tests also pass against the latest build of the software. Our Continuous Integration server will take care of that over night.”
After Eric finished the debriefing, Peter went home, constantly reflecting over the day.

Rant: I f$%&ing hate working remotely!

Just to set the tone straight: I hate traveling for work just like the next person. But today, I’m covering why I hate working remotely even more than that.

I track my work-related travels over tripit. At the end of each year, that website informs me about my travels. Occasionally I tweeted out the statistics from the end of the year. I think its peak was in 2012 when tripit told me I was on the road for 304 days that year. Since then I cut my travel time every year a bit, considering just the conferences I really wanted to be at, and the like. Even pre-pandemic, in 2019 I still had over 200 travel days for work-related travels. So, when I say I hate traveling for work, you might get a clue.

During the pandemic, in 2021, I had zero travel days for work. For the first time since 2010, I had zero travel days. ZERO! That must have been awesome, right? Well, not really.

Over the course of the past two years, most companies sort of had to learn how to work in a dispersed way, with teleconferences all over the place, almost all white-collar workers joined their home offices and their families. What a great pleasure it has been – not!

Over video conference systems you can still get real-time conversations with people in another room, in another town, in another country, in another timezone, true. But notice how limited your remote picture of that other person is. Are you sure, the person you’re communicating with is wearing pants today? Or the color of their socks? Or how their feet start tapping nervously whenever you start to talk? Yeah, guess what, you can notice all of this stuff when you meet with people face to face, in person, in the usual three space dimensions we call the real world.

Even with extraordinary measures, you will still lack many sub-conscious communication channels that we humans got so used to when meeting another person and can see, touch, and smell that other person. The communication channels at play are so much richer, and over the past two years, I almost forgot about this.

My first in-person training since October 2020 took place in March 2022. That’s one and a half years I forgot about all the other communication channels that I use to read the room and get a glimpse of what is happening for my participants. Instead, in remote trainings I had a way more limited set of communications to use.

While preparing for my March 2022 training, I took a look into older photo protocols, pre-pandemic, from 2020. I was amazed by how little I had noted down on flipcharts compared to what I covered on my miro boards during remote trainings. Did I cram so much more content into my classes in the past two years? Not really, but I only noticed this after entering the training location in March.

With all these additional communication channels, I got to see three different groups working in parallel and still noticed immediately once a group needed my help just by the energy in the room and in that corner of the room where the people were working. So, I could immediately jump in to help them. Additionally, the participants asked WAY MORE questions in person where I could explain a concept on the spot, that may or may not have made it into my remote training materials. During that one class, I noticed how much more communication was happening in the group and with me as the trainer.

That experience repeated and repeated with every course I gave since then.

But wait, it gets better. My work schedule also got less jumping from meeting to meeting. When I had my first on-site coaching client since 2020, I was on the road, wandering around in the offices, having a coffee corner conversation here and there, and no one bothered to cram in another remote meeting in the 15 minutes breaks I might find in my schedule. I could focus WAY MORE on the client.

Compare that to some of the years prior. I remember weeks where I had used Zoom, Teams, WebEx, and some weeks all of them in basically two days alone. Don’t get me wrong. All these tools are great, but yet, they lack much of the on-site, face-to-face experience. Jumping from client to client, tool to tool over the day, unfocused me. There were days when I felt drained of my energy just by the mere context switches I endured through my schedule.

All of that said, I have a hard time understanding some of the arguments raised in this time of transition back from mostly home office to on-site meeting with people. By my estimate, just by working remotely, I think we humans only can bring 20 to 50% of our productivity to work, not even taking into account the misunderstanding of bad audio or internet connections.

In 2020 one of my clients started a discussion internally. The higher management raised the point that they were unsure how much office they would need post-pandemic. I heard side conversations from training participants back then on how that was discussed. For me, the benefits of real-time, face-to-face conversations that are not limited by the activity of background programs outperform anything I can achieve remotely. So I find this discussion of the number of office spaces still broken.

Having said that, this week I agreed with my client to stay home since I had an unsafe contact marked on my phone on my way back home, and we found it more suitable to stay home this week for that reason. And I start to realize again how much I hate it. I just hate it!

Remembering Jerry: Becoming a technical leader

It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. In the coming weeks, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. I struggled with the order I want to go for these books, chronological, topic-wise, in the order, I read them. Even after consulting my network, I don’t have a clear picture there, so I will basically just go with “whatever I want to do this week”. So, the first book I picked is Becoming a technical leader – An organic problem-solving approach published by Dorset House in 1986.

I’m so glad that I took this book with me when I attended the Problem-solving Leadership (PSL) class in Albuquerque, New Mexico back in 2011, and had the opportunity to meet Jerry in person for the first (and only time). I asked him to sign my copy of the book not only because it fitted the topic of PSL, but I think it’s the first book I read by Jerry, ever.

So, let’s dive in what I remember from the book after all these years.

The general model and approach

In general, Jerry describes his MOI model regarding leadership: motivation, organization, and innovation. A fourth piece deals with transforming, i.e. changing things on a group of technical persons.

Motivation

On motivation, Jerry’s book is pre-dating Dan Pink’s book on the matter by a few years. While skimming through the table of contents for this review, I realize there is probably more in here that I took by hears, i.e. “Help should come natural”, the Satir interaction model, and congruence. I attributed many of these models to different books of his, yet, wasn’t fully aware how much in my past the first introduction had been.

Organization

Over the years, my thoughts on the organization part have faded as well. While going through the table of contents again, I see some great pearls of wisdom in here as well. Jerry names the four obstacles to organization the following:

playing the Big Game (I don’t recall what that was at all)organizing people as if they were machines (oh boy, guilty as charged)going the work yourself (I plead guilty to this second charge as well)rewarding ineffective organizing

Just by reading the headings, I get an imagination of what lies in there. Even though I seem to have forgotten many of the pearls surrounding it, I sense that my thoughts reconnect with what Jerry would say about these different topics.

Innovation

Right from my head, I had the most vivid recollections from this part: innovation. In the first few chapters of this part, Jerry describes the biggest obstacles to innovation, namely: self-blindness, the no-problem syndrome, and the belief in single solutions.

Of course, Jerry continues to offer solutions to overcome these shortcomings. To tackle self-blindness our human innovation driver stems from learning mistakes. The no-problem syndrome is overcome by what many in academia do: copy an existing solution, thereby stealing it. Lastly, the opposite of believing in single solutions is copulation of two existing good ideas into an even greater new one. I recall referring back and forth to these three archetypes for innovation over the years, often revisiting mistakes, copying, and copulation whenever a problem regarding innovations came onto my plate.

Transformation

Regarding transformation, I first thought, that I had more livid memories from his change book in the Quality Software Management series. Then it dawned on me, that Jerry actually challenged me about changing things in my daily routine. His point was to change a small thing that you usually do on auto-pilot. In my instance, I went for a different Saturday morning breakfast routine back in the day. At the end of the weekend, I noticed how just that tiny bit changed my perception of the whole weekend. I think that’s a pretty powerful point, and there is so much you can change in your daily routine to get used to changes yourself. Take a different drive to work, change your breakfast, shuffle things in your morning hygiene routine – and observe what else changes during your day. Arrive early at work, arrive late at work, sit at a different desk, there are so many things in our daily life that we appear to do on auto-pilot. Just changing one thing can have a butterfly effect to change your whole day, and even your whole life.

My main takeaways

After all these years my main takeaways from Becoming a technical-leader were the innovation model, changes in your daily routine, and journaling. In a few introduction sections, Jerry speaks about leadership, and the best thing to start your leadership journey probably is to start a daily five minutes personal journal. If I recall correctly, I made some of my personal journal entries public, but also kept many of them to my own. Even though I may have given up my personal journal over the years, I sense a deeply personal reflection every now and then that still stems from me learning about the personal journal lesson from Jerry.

One piece of advice before you head out to get a copy of Becoming a technical leader – or any other Jerry Weinberg out there: Over the years, I had conversations with very many people about his books. For some, Jerry brings the same value as to me, while others found his books quite unreadable. There did not appear to be an in-between. I always enjoyed the timeless way Jerry wrote his books with many nuggets of learning still relevant after decades. Since Becoming a technical leader brought me a quite positive start, I decided to continue reading his books.

The Deliberate Tester – Chapter 1: Session-based exploration

Back in 2011, I approached Rob Lambert at the Software Testing Club on a small series, packed into a narrative format as I wanted to try that out. Rob decided to run that series on the Software Testing Club back then, and I had some fun writing it. Skip forward 11 years, and the Software Testing Club no longer exists, it’s been a while since I have been in touch with Rob, yet I figured, let’s see how this series aged over the years. As a sort of throwback Thursday for myself, I will publish the entries on a weekly basis, and read along with you. I think I ended up with eight chapters in the end and might add a reflection overall at the end. So, without further ado, let’s follow Peter’s tester journey along while gets familiar with session-based test managemet.

Chapter 1: Session-based exploration

Peter took a deep breath as he opened the door to BigSoftware, Inc. While studying at the university, he’d done an internship, but this was his first real job. He was especially nervous because his Masters degree in Computer Science hadn’t covered much about software testing… or had he just been disinterested? Peter remembered the Software Engineering course he took in the fifth grade. On one of the slides with the V-model, there was indeed software testing mentioned, but Peter couldn’t remember anything from the lecture about testing.

Peter entered the building and moved straight to the receptionist at the front desk to introduce himself. He did not get specific orders for when to show up to work on his first day or who his superior will be.
“Good morning, ma’am. I’m Peter…”
“Peter Smith?” The receptionist seemed to know him.
“Yes, I’m Peter Smith. It’s my first day here.”
“I know. Let me call Mr. Johnson, your superior. He will introduce you.”

A few minutes later a tall man arrived at the reception.
“Hi, my name is Johnson, Eric Johnson, you’re Peter Smith?”
“Yes, I was…”
“Don’t matter. They always forget to tell our new colleagues when to show up.”
“Ok, Mr. Johnson.”
“Ah, first things first, please call me Eric. We call each other on a first name basis.”
“Alright, Eric.”
“Good, now, let me show you your new workplace.”

Peter followed Eric along the floors of the tall building. Along their way, they came past several offices and meeting rooms. Peter tried to read some of the names on the door signs, but remembering names wasn’t Peter’s best-developed skill.
“This is your desk,” said Eric, when they finally got into one of the offices.
“This is your computer. I set it up just yesterday. Let me give you a short introduction to our business before I introduce you to your new colleagues.”
Eric started to explain a lot of things. The more buzzwords Eric used, the more Peter got distracted. Peter asked a lot of questions when Eric showed him the documentation of the software. Peter felt really dumb after Eric finished his little introduction. Peter wondered about all this knowledge that he acquired at the university, but that still did not tell him what to do in order to test software.

Eric took Peter after his little introduction into business matters.
“Ok, Peter, this is Jennifer. Jennifer is our senior exploratory tester.”
“I read a lot about the software and business behind your work here. Now I’m eager to see the application.”
“Oh, come to my place when you finish your round through the offices. I got a session scheduled later, where I might give you a short introduction.”
“Great, can’t wait to see more.”
Eric and Peter finished up their round through the offices of the other testers in Eric’s department, then went over to the developers sitting next door. Peter tried to remember some of their names, but being confronted with so many new names was a challenge for his memories. Besides, he still didn’t know how to test software thus far.

Peter joined Jennifer in her Exploratory Testing session. Jennifer popped up the main screen of the application, which Peter already had seen in the documentation he read earlier that day. Jennifer explained her approach.
“I work in time-boxed sessions. Before starting a session, I sit together with Eric to define a mission. The mission may be to test around some of the bugfixes we got in the latest build from the development team, or to find bugs in new features of our product.”
“Ok, this sounds easy.”
“Yes, it sounds easy. Over time you will acquire some skills in finding critical areas in the product. There are some traps you may fall into. Behind each step, there is a lesson to be learned.”
Jennifer started to walk through some business flows of the application. Peter sat down and watched her, interrupting with some of his immediate questions that came to mind. After about an hour, Jennifer said:
“Ok, that’s it for now. Let’s do a debrief.”
“A debrief?”
“Yes, after each session we sit together and discuss what went well, summarize the bugs we found, and reflect over the session. Let’s go to Eric. He’ll do the debriefing.”

When Jennifer and Peter arrived at Eric’s office, Eric immediately waved them in.
“So, Peter, how was your first Exploratory Testing session? What did you learn?”
“Well, first of all, I learned a lot about the product and the business behind it. It was a great experience and Jennifer taught me a lot in just a single hour. Though, I’m still a bit unsure what software testing is.”
“Ok, great. What do you think Jennifer?”
“Well, Peter is a great tester, he just doesn’t know, yet.”
Peter turned red on such appreciation.
“He needs some experience though in order to get conscious about his testing.”
“I got a question regarding the Exploratory Testing I did this morning,” Peter interrupted.
“Shoot.”
“Well, I figured all the testing we did was done just manually. Do you exercise the product with each new release?”
“Yes, we get a release build each night and explore it over the next day,” Jennifer answered.
“But, isn’t this… sort of… boring? All the repetition?”
Jennifer and Eric looked at each other for a moment. Peter started to feel uncomfortable about the silence in the room. Then Jennifer and Eric started to laugh.
“Well, if Exploratory Testing was all we were doing, that would be boring.” Eric started to explain. “But there is more to software testing than just exercising the software. Let me introduce you to John right after lunch. John is a former programmer and works on our automated tests. He’ll show you some of the automation of the repeated tests. By then you should get a better overview of your work as a tester.”
“Fine. That sounds interesting.”
“Now, to the technical part of your testing…”

Working on overcoming Imposter Syndrome

For a couple of years now, I saw conference talks on the imposter syndrome coming up every now and then, from different people in the field. Ever since I started to deal with my own “manipulator”, I figured it could be helpful to some people out there interested in trying the first steps in overcoming imposter syndrome on their own. Please note that the following has helped me in my journey. I don’t dare to say this will work all the time for everyone. It worked for me. So, maybe someone else is similarly as weird as I am, and it helps that person, too.

Some background

The following has a variety of influences. My earliest influence probably came from Secrets of Consulting by Jerry Weinberg (or was it More Secrets of Consulting? not sure) where he explains an item that he carries with him, that reminds him about his strengths, and how he wants to be courageous in different situations. I recall him calling this item his courage stick.

Of course, if you start reading Jerry Weinberg’s work, sooner or later, you will cross lessons from Virginia Satir. The stage director metaphor stems from the book “Your many faces” where she walks through a dysfunctional case first, then a one where the person stays in charge of the stage direction.

Other influences include Schulz von Thun and his writings on Gestalt therapy, as well as my recent encounters with the various materials in the ORSC cosmos. I recall a recent coaching session as a personal coach based on this.

While working through my steps, please make sure to not dive too deep into reliving your imposter moments. Especially when I mention detaching yourself from that recent experience, it’s important to live into just enough to get a brief connection, and not put into a realm. If you try this just on your own and find yourself always stuck and unable to detach yourself from the situation you worked through, find a person that can walk you through the steps, and be able to detach you from the imposter moment. Otherwise, you will have a very unpleasant situation relived, yet, still unable to turn this into anything more productive. Avoid that at all costs.

The stepsSit comfortably. Think about a recent situation where you felt – in hindsight maybe – that you encountered an imposter syndrome situation. Something is telling you that you’re just faking it without really knowing anything. Feel briefly back into that situation, just enough to get connected.How would you describe that feeling? Does it make some noise? Is there a particular smell? Is it some kind of person standing beside you? Try to find something on a sensory channel that represents that imposter moment. Make sure to not get too deep into it. If you feel anything overwhelming you, take a break, and maybe find another person able to safely guide you through this, yet keep you detached enough to not block yourself.Amplify and dampen the noise, smell, the person. Make the noise really loud, then turn down the volume. This might be especially tough for a moment to stay detached.Now, literally, take a step back from that situation. We’re in the here and now, you’re not in the situation at this point, but outside of it. We are able to take a look at that situation. What else do you see from this outside perspective that you could not see a moment ago? Something that makes you curious? Something that makes you fearful? Briefly describe it to yourself or the person guiding you.While continuing to look from the outside at that situation, how would you describe yourself? Can you find a suitable name?Start a conversation with your imposter moment self. What is the imposter moment self saying? Listen to yourself at that moment. While staying in the here and now detached from the situation.Having listened to yourself in that situation, how do you think that imposter moment is trying to be helpful to you? Everything happens for a reason. Some of our thoughts are guided by our past experiences, and that holds for all of us. Probably some previous experience might want to warn you about some unpleasant that happened, but you forgot about it. Try to take a look behind the curtain of your own self. Stay rationale and in the here and now while digging into it.Since you are in the here and now, and now tasted a bit of how the imposter syndrome may want to help you, with the current detachment, how would you respond to your imposter moment self? What do you tell it? What kind of gesture do you offer? How does your imposter moment self respond? Try to have a conversation with it.Maybe change your position and completely detach from the imposter moment. Maybe stand up, and shake your hands and legs. Turn yourself around 180 degrees.Having gone through reliving this moment, and starting a conversation with your imposter moment self, what do you take away? How would you like to be reminded about the helpfulness the imposter moment self is trying to offer? You are now in the position of the stage director of your own inner stage. How do you welcome the actor in the imposter moment, and make sure that its voice is going to heard?Maybe find a gesture, item, or touch on your own body that will remind you of what you learned as the stage director. This could be a touch on the elbow, an item like Jerry’s courage stick, or a scratch on the foot. Anything that will help you remind you of this situation.This last step is important: Before going into the next situation where you fear getting into an imposter moment situation the next time, rehearse the situation. Try imagining forward into the future, and remind yourself of the gesture, touch, or item from the previous step. How are you going to respond? Keep in mind that you are rehearsing the situation as the stage director. Make sure to incorporate other different actors that show up on stage as well in check, and make sure that you are directing, not them.Final disclaimer

These steps are not guaranteed to succeed every time for everyone. It might be the case that the first two tries after the rehearsal do not work at all for you. Consider working on the next most recent situation again, getting outside guidance and help, and in extreme cases seek a totally different approach, as this one might not be working for you, but another might. If any of these situations make you feel uncomfortable, stop immediately, take a break, 10 minutes minimum, a couple of days is fine as well.

At some guided sessions I started to name my imposter moment self the “manipulator”. It took me a while to get used to noticing him showing up for me. Sometimes I miss that moment totally, and he starts to bring up his warning in unskillful ways. That’s ok. As you learn forward, you will get better at recognizing these moments for you earlier, maybe once or twice welcoming the “manipulator” to the stage, and providing him the feeling that his warning is now heard and addressed, mitigated, or whatever seems suitable. The more you practice, the more often you will notice that you stayed in charge as the stage director.

As I can’t stress this enough, get outside or even professional help if these steps do not succeed for you. An experienced coach or psychologist will be able to guide you through these moments and keep you detached, or have her own approach to getting you through it once she sees all the other clues that you are unable to see for yourself. For me, this approach worked over time. You might have different experiences demanding different approaches.

“I’m an architect.’

A few years back, I ran a public course in Düsseldorf, Germany. While looking through my options for one of the evenings, I noticed a public Coding Dojo run by the Softwarkskammer group there and decided to have some coding fun in the evening. During the dojo, I had an experience with one of the attendees that I keep on sharing every now and then.

I think I wrote up on this a while ago. Since I keep on referring to that experience, I thought maybe a reflection on what I think happened a few years later, might be helpful.

The setup

Upon arriving at the venue, there were five or six other people with me. The host, Georg Berky if I recall correctly, had invited us to do the Mars Rover kata. Georg explained the idea of a coding dojo and how we would be working as an ensemble that evening.

During a quick round of introductions, we introduced ourselves to each other as most of the folks there did not know each other. One of the participants introduced himself as an architect at his current employer. I remember me thinking: “Oh, how awesome we attract also some architects with these Coding Dojos, maybe making a real change in their organization.” Oh boy, was there a surprise going to come up on me.

We decided to go with Java as programming language to solve the Mars Rover problem after Georg introduced the problem we should solve, and we sketched a couple of worthwhile test ideas to get us started.

The beginning

We had the first pair start us off. I don’t recall whether the self-identified architect was in that group or not. I just recall him during the first few tests lamenting on how all this test-driven development was not worth the time, thinking harder about the design, and then just writing it down, was the way to go, and so on. I guess you might have heard some of these arguments over the years.

Anyways, the timer rang, the pair rotated, another person joined, and we continued to make some progress despite the side comments from the architect person. After 30 minutes or so, we had come up with two different classes to solve the kata. I don’t recall how we named those two classes and what their responsibilities were. I just recall how I noticed something curious. One method in one class was calling lots of functions on an instance of the other class. That raised my awareness, and when the next test was made to pass, we even added another call to that other class to that function.

I raised my opinion that the behavior we put on that one class really wanted to be part of that other class instead, and we should refactor the existing code to move that function there. In my memories, the architect blurted out how that would not have happened if we had spent some time on the design up-front, and the like.

The refactoring

We had a brief discussion about how to conduct that refactoring. The person on the keyboard tried to use the automated refactoring support in the IDE, but the IDE refused to do it since it considered the move unsafe. When the group was close to continuing without the refactoring, I said I might know a way to do the movement in a series of steps, and offered to jump ahead on the queue and show them how I would tackle it. The group agreed to put me on the keyboard.

I don’t recall the exact steps I took after all these years. I created a new function on the other class and moved created a new method on the first class that was delegating to the other class. Then I slowly moved over some of the functionality one piece at a time. At a certain point the architect blurted out how I had created a cyclic dependency between the two classes with all my steps now, and how that was bad and had we thought about the problem to solve more intensely in the beginning, we would be done by now.

Then I pressed to key combination for “Inline method” in that IDE, the old function on the first class was gone, all behavior was now on the other class, and the cyclic dependency was gone as well.

Silence.

“How did you do that?” was the next question raised by the architect. I showed him what I had done, and he seemed pretty surprised.

The takeaway

Different organizations have different career expectations. “Architect” in one organization can mean totally different things than in another organization, “tester” in one company can be totally different from a tester in another.

Most of my recommendations were highly motivated by the books I read over the years, probably the classic Gang of Four Design Patterns, Refactoring, Refactoring to Patterns, and Growing Object-oriented Software – Guided by tests. When I realized that the “architect” did not know about one of the most basic refactorings available in a modern IDE, I left that evening with the sense, that he may not have known much until that point. Unfortunately, those particular knowledge gaps led him to believe that his thinking was the more righteous one.

Today, I think, from his frame of mind he was correct. And we were correct from our frame of mind as well. It turned out as a happy surprise that we were able to learn about our different frames during that coding dojo.

And it intensified my belief that we’re merely at the start of teaching programmers about how best to work in a modern, agile working environment. Today, I think we have not much progressed, unfortunately, but we’re steadily continuing to do so, and fight crappy code along the way. Bring it on!

Team interaction pattern: the ambassador

A couple of times, I found a particular pattern of interaction from a team with some other group (or team) useful. I would not recommend it all the time, but there appear to be appropriate use cases every now and then. Since I didn’t cross similar thoughts in the Team Topologies book, I thought it useful to write up as inspiration for others. Let me introduce the ambassador to a team.

Some background

The first time I saw this kind of interaction at work was a couple of years back at a manufacturer. They used Scrum to build up the first prototype of their new mid-priced product. They were already in the market in the low-, mid-, and high-price market with their product, yet their mid-priced product needed a revamp to keep up with the competition. The product development consisted of prototyping, CAD of the interaction of the different hardware components, some electrical board design, and software development.

As the Scrum Team made more and more early design decisions, they needed to interact with the purchasing department that finalized the contracts of various suppliers, both for the prototyping phase as well as the final mass-manufacturing conditions. Each Sprint the team settled on a combination of decisions, that was explored in the purchasing department by a different department. Usually, contract negotiations with vendors took about six weeks in most cases and included PCBs and raw materials for the construction part.

Since all these different vendors and product raw materials had varying expertise on the purchasing side, there were three to five different people involved from the purchasing department. Depending on which component you were looking to settle a contract, a different person might come into play. Since the work from the purchasing side took six weeks most of the time, it was hard to incorporate into the product development Sprints, yet, there was a high demand for interaction between the Scrum Team and the purchasing department, i.e. to review proposed parts and conditions on candidate contracts before deciding on a particular vendor.

In this company, on this Scrum Team, we worked with a fixed person from the purchasing department. That person would join the Daily Standups, on-demand attending the Sprint Planning, and maybe the Sprint Retrospective. Whenever the team needed something from the purchasing department, they had a go-to person from the purchasing side, that took the Scrum Team’s requests and coordinated with her colleagues from purchasing to fulfill them. Over time, I started to call this person the Scrum Team’s ambassador from the purchasing department.

The Ambassador – a brief description

If a Scrum Team needs to interact with another group of persons often, yet the nature of work of that other group is so distinct from the Scrum Team, it makes sense to have a fixed go-to person that takes care of the necessary coordination for that other group. The other group maybe a group of persons working alongside each other with their own fields of expertise, or another team, I recently found it.

Note, as is the case in politics, the ambassador might have a spectrum of decisions that she can take on her own. The broader the decision spectrum of the ambassador is, the more timely decisions from the other crucial group might get back to the Scrum Team. In that case, the Scrum Team will less often wait for decisions from outside the team.

Another note: the ambassador may bring one member of his group together with the Scrum Team to carry out the coordination work, or do it on his own. I see a parallel to the ambassador in politics there as well. Some negotiations are carried out by the ambassador on her own, others are carried out by her staff, and it’s totally up to how the group of the ambassador is organized on how the coordination happens.

Other uses where an ambassador seemed reasonable

Last year I was involved with a Scrum Team in a similar situation to the above example where this ambassador role came to my mind again. At my current client, I found this role useful in a slightly different setting. The work they do appears to make the most sense to split up into an enabling team and a stream-aligned team in the first phase. Once the enabling team managed to enable a particular functionality in the developing application system, the two teams change their interaction mode to full collaboration in the second phase. During the first phase of the development, while the group is split into an enabling and a stream-aligned part, an ambassador from the other team would be useful to have for both teams.

Overall, I am not sure to which extent the ambassador should be temporary as in the latter example I mentioned, or permanent as in the case of the team in the first chapter. Personally, I would strive to keep it as a temporary construct while we learn forward on how to bridge the limitations that demand two different groups working toward the same goal in parallel. That seemed harder to overcome in the hardware case, and looks possible on my current project, though it might take some time. The ambassador can ease some of the pain for the time being.

Please share some of your own experiences in the comments if you happen to make your experiences with an ambassador.