Testing Talks is a series of interviews highlighting well-known personalities from the world of software quality and testing. In this new episode, we had the pleasure to talk with George Dinwiddie.
George Dinwiddie is a software development coach who helps organizations develop software more effectively. He helps organizations, managers, and teams solve the problems they face by providing consulting, coaching, mentoring and training at the organizational, process, team, interpersonal, and technical levels. He is also an Owner at iDIA Computing.
Can you introduce yourself and your background?
After 25 years of engineering, a few years of working in hardware and then transitioning to firmware and then software, I have been an independent consultant and coach for 18 years now. I actually wrote my first multiply routine from a Schematic. And before that, I had a number of jobs: I was an audiovisual technician, an organic vegetable farmer, a theater, lighting, and stagehand… And way back when I was 14, I was a TV repairman!
How did you get started in the software development industry?
In the early 1980s, I was working on a custom digital signal processing chip for a modem adaptive equalizer. The controller for this circuit was a state machine, and basically it was programmed in pure machine code. So I got some real inside information on how a processor works by working on that. Around the same time, I was working on building my own CPM computer too.
You wrote a few articles about Agile. What do you think about the future of the Agile Method?
When I discovered Agile, it mostly already made sense to me because it was similar to the way I already worked. To start with a small working system and evolve it over time, building along the way what you need to make. That way, it is easier to verify that things are working. So the part that didn't make sense to me with extreme programming was the first part. Because coming from a hardware background, I couldn't imagine how you could test something that didn't exist. I was very skeptical. But I was communicating with people that I respected, and they said it worked for them. So, I gave it a try and that also worked very well for me. This was before the name Agile had been applied. It was called ‘Lightweight methodologies’ then, and these approaches and new refinements will continue to be used by people in organizations who want to get things done – both well and expeditiously.
There will also continue to be people in orgs that are somewhat insulated from the consequences of their actions, who will think that they can plan it all out and then have people follow that plan. That's their loss.
What is the biggest challenge you have ever faced, and how did you overcome it?
There have been so many challenges and many of them very different from each other, and I survived them all. Perhaps, the hardest for me was learning how to effectively help people. I grew up thinking in technical terms, and I used to think that telling people the answer was sufficient. But that didn't provide the results I saw. People like Dale Emery, Jerry Weinberg and Esther Derby helped me get on the road of learning more effective ways of working with people.
What do you love the most about coaching people in software development?
I love helping people, I really do. I also love to learn things. With the two of these, it gives me great joy to see other people brighten up when they learn something that helps them!
What advice do you always give about software development?
I like to remind people of Larry Constantine's concepts of coupling and cohesion, which I think are the basis for almost all good software design and architecture. A lot of the more complicated patterns are really just layered on top of that, or specific ways of achieving that.
What are the main points to succeed in Agile Transformation for you?
There are two things that I think are terribly important that are often not given enough credit when people are first starting out. And the first one is to take small steps.
And to pay attention to what's happening. This works both with the code and with the transformation itself. Try things, look at the results you get and adjust.
The other is to respect people and honor their humanity. So often people who are used to working with machines get in the habit of doing that and treat the people around them as machines also. But they're not. They're living, breathing people who have ideas of their own. And their ideas may work better in this situation than the ideas that you started with.
You wrote a book about test automation code. Can you share with us any goods about the writing of this book?
The book is Evolutionary Anatomy of Test Automation Code. And it's available on Leanpub.
Lisa Crispin contacted me. She was on the program committee for the first Agile Alliance Technical Conference, which was in Raleigh in 2016. She asked me if I would be interested in speaking there, and I said: ‘Sure’. I would go along with almost anything Lisa Crispin asked me, but this was not a hard thing to agree to. She asked me: ‘What's the title of your talk?”. I thought about how the online examples of test automation tend to be very small. It's showing off a particular tool in its capabilities, and they don't show how things change over time. They don't show how to grow a system using that tool. And so, I thought the Evolutionary Anatomy Of Test Automation Code would be a good topic that the industry really needed. So, I gave her that title, and it dawned on me that in order to produce this talk, I was going to have to write a significant code base to demonstrate the things I was talking about. I spent a month working by myself on this code – and it's probably not the best code I've ever written. I didn't have anybody to bounce ideas off with and nobody looking at it with me. And also I was fitting this in, with other things I was doing. But I developed this code. It’s not just the code, but it's the history of the code to get as I went along. I finally got the code done, and I took notes as I went along, and I sat down to do the talk and that was tough. My first draft of the talk turned into the book. I spent more than 40 hours over one weekend writing the first draft of the book to try to organize the talk. Then, I showed what I had to a colleague, and he said: ‘How long is this talk?’. I had to cut out most of that from the talk, because it would be way too long. But I did polish up the book and publish it on Leanpub.
What would be your best practices for writing good test automation code?
The most important thing with test automation code is it needs to clearly communicate the intent. I don't know how many times I've come across organizations and programmers who have exercise the code they've written and demonstrate to their satisfaction that it works. But you can't tell what the system is supposed to be doing when you read this, and that makes it very hard to understand later on when something's not working. Well, what was it supposed to be doing? And it makes it very hard to understand where the holes are in this test coverage, what things are not tested. The other thing is that test automation is code also – and it needs – to be maintainable for the long term. Now, making the intent clear helps you maintain it. But, it also needs to be well-structured and structured for its needs. Now, there are some differences between the structure of test code from production code, but still a lot of the same concepts happen. So, the code also has to describe itself.
Your final takeaway for this interview?
My advice is: take pride in what you do. Whatever it is. And never stop learning. And if you get stuck, ask for help. There's almost always someone around who can give you some feedback, some ideas, even if you think that they don't know as much about the topic as you do. Sometimes the novice questions are more helpful than what someone else who has been steeped in the problem might ask. And if you don't know someone to help you, don't have someone available, reach out to me! Like I said, I love helping people. And I'd be glad to look at it with you!
.png)
