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 Venkat Subramaniam. Here is a digest from his interview.
Can you introduce yourself and your background?
My name is Venkat Subramania. I consider myself a programmer. I have been programming for a few decades now. I started programming with C++, mostly in the area of chemical engineering and refineries, and I got really excited about programming languages along the way. At the moment, I program in about 15 different languages. I'm not good at any one of them, but I'm really excited about languages. I spend most of my time training, consulting and mentoring. I go around the world to collaborate with teams. Predominantly, my role is what I would call raising the power of the teams. And I strongly believe in what is called sustainable agile development. I focus almost entirely on technical practices when it comes to agile development, whether it is automated testing or improving the code quality, focusing on the teams to work better together at a technical level. My role consists in either training the team to get better at automated testing or consulting and mentoring with the team, to hands on practice in their projects. The purpose is to help them move towards and to adopting certain technologies.
How did you discover agile methods?
I came by agile methods before the time agile methods was actually coined. I remember, way back in the late 90s working on a software project. I had this one experience - with a critical client - that was like a light bulb moment. My boss essentially called me and said, “Hey, this project is top priority and you're going to lead the effort”. I said “Great, can you tell me more?” He said, “It's due on number first and you better get it done”. I realized that the only chance to succeed was to constantly collaborate with the customers. So I called them up and asked if it was possible for them to weekly test our versions and to share feedback…
Doing so, we actually delivered it a few weeks ahead of the schedule. I was honestly a bit shaken because I went a completely different route than expected.
That’s only a few years later that I realized I could write a book about that experience. With Andy Hunt, we co-authored “The Practice of an Agile Developer”.
What do you love the most about your job?
I like to say that I am like a kid in a candy store. Every single day I wake up with excitement because this is a wonderful experience. We live in this world where we can create abstractions in our mind, we can come up with ideas, test them, see them, …. When I started programming a few decades ago, I got into programming like a lot of people. Math and science drew me into it. But what really keeps me excited today is the art in it, the excitement in it, the amount of things we can create in terms of value to customers. In most industries, we do not have this luxury of being able to sit in front of a machine, conceptualize it, create something and be able to deliver. One thing that excites me is that we can create things. The other thing is the fact that I can work with developers around the world, and have them really think through the solutions and challenge themselves in applying these ideas differently and get the results.
What is also exciting is that there are no fits for all solutions. We need to take a problem, think through it, and identify a simple solution that can give us the expected results. This is a combination of working closely with both people and technology and the challenges surrounding it, and then being able to cause an impact and deliver results. (...) It's fantastic to have that very humbling experience where you get to really contribute on a daily basis and at the same time realize that there is more to do, more to learn, more to offer and that's absolutely rewarding. I cannot even imagine being in a field where there is nothing new to learn or nothing new to excel.
(...)
What do you think about automation in software development?
Let’s step back a moment. 30 years ago, it was my first trip to the Grand Canyon. (...) Got into a car, (...) I was driving 2 hours into it, I stopped the car on the side of the road and asked “Am I heading in the right direction? Am I lost?” I had two options. I could keep driving, maybe get lost or drive back to civilization until I ask somebody the right direction.
And you may say: “Oh Venkat, didn't you really have a map so that you could know the direction?” Certainly, I had a map with me. For little younger kids these days and even young developers these days, this is a little hard to relate to, because we used to have paper maps back in time. So I took this huge paper map, but it was missing just one thing, a blue dot. Today, we have electronic maps. The map itself is not really useful, but that blue dot is.
So the questions are:
- Where are you?
- Which direction do you need to go?
- How far do you need to go?
We, as humans, thrive when we have that feedback loop.
If I step back and wonder what agile development is, my definition would rely on feedback driven development.
If you remove the feedback, effectiveness is reduced. When it comes to software projects, there are two different feedback loops that are very essential.
The first one is am I creating something relevant, or am I just writing code?
In fact, and in my opinion, I feel like the Agile Manifesto misses a word. They said we should create working software. But I think what they really meant was we should create working, relevant software. Because if you're not creating something relevant, our efforts don't matter. (...) This is where the feedback loop comes with business units, business analyst and QA interactions.
The second feedback loop is understanding why a code worked yesterday and not today. Well, it turns out software is a nonlinear system. Imagine you have a building, and you put a book on one side of the bookshelf and something falls from the other side. That would be weird. You do not want things to behave that way. But that's a reality in software development. It's not cost-effective. It's frustrating. It keeps us away from delivering value. So the question is “How do I make sure that the changes I made aren't affecting other pieces of code?” That's a feedback loop.
In agile development, we want two feedback loops at the same time. The loop of relevance as I like to call it and the loop of regression… If you remove that feedback loop, that's like going blindfolded and walking through the room. Yes, eventually I can stumble my way through the destination, but I'm not being effective. That’s a waste of time and money.
Instead, let’s proactively invest that time and money in building automation to the right degree, to the right level to enjoy the feedback loops and reduce the cost.
(...)
Would you rather teach beginners who know nothing about Agile methods, or experienced people who misuse agile methods? And why?
I love learning with the people I teach. I often jokingly say that I am the first student in the classes I am in. From a learning perspective, I think we get to learn from both groups of people. I was just teaching a group of people last week, and among the 20 students, some of them had about two years of industry experience or even less. Others had literally 35 to 40 years of experience. And what is absolutely fascinating are the questions you got asked. Newcomers may ask: “Why do you do that?”. Older generations might ask: “I am doing it this way”. So in both situations you have to rethink your reasoning in different contexts.
At the end of the day, you learn more about empathy, pragmatism, realistic situations, and offering solutions that different groups can embrace. The challenge is not just achieving the goal, but also assessing where we currently are and where we want to go. So, the same solution may be easy for some but challenging for others due to their different environments.
More effort may be required to break out of the current situation in order to transition. When dealing with different groups, we can become dogmatic, prescribing and describing what to do, leaving others to scratch their heads, saying it won't work. Imagine you teach one group and you're excited about it, but the reality is that group doesn't work in isolation. They have to go work with other people. And now we are addressing the needs of one group, but naively. Without considering the holistic context in which they work. So, I would say the process really is to help the teams to get better. And if we can learn with them and empathize about their situation, be realistic and pragmatic about our solutions, I think we can deliver better results then after all, this whole process and everything we do is really to get results to where we want to be.
So if we can ask “How can we get the results?” I think it's important to bring those teams together and learn with them.
I like to teach groups that are mixed in experience and expertise. And if the question is, “How can you convince someone who may be inconvincible, and how can you convince somebody who is eager and thirsty to really absorb all of that and then bring them together to move towards getting the results?” That's definitely exciting to have that opportunity. And thankfully that's a reality as well.
How should companies organize their dev teams?
What we know as Conway's Law, says that the communication structure in the organization is influencing the structure of the applications we create. I have the very firm conviction that the key is collaboration. The more we separate people and make it harder for them to communicate, the more difficult it is for us to develop proper software. I have worked in different teams over the past. In teams with subteams working in silos and where they hide behind their own desk to develop software. They may communicate within a small group of people, but have a barrier to communicate across. I have seen teams where they separate programmers from QA, not just by rooms or buildings, even by continents. And it's absolutely mind-boggling to notice how they actually make it harder for these people to communicate across each other. But that’s ineffective. The organizations I consider successful are the teams where we have people that can reach out to each other. Literally, a programmer can drag his or her chair and sit next to a tester and talk about writing automated tests for a particular feature.
The tester can drag the chair, sit next to a business analyst and a programmer and discuss the details of what they are focusing on in testing. I'm a huge fan of pair programming and mob programming. Software is a collective game. There's no fun in being the best player of a team that never wins. And I would rather be an average player of a very highly successful team rather than being the rock star of a team that never delivers the software.
What we don't need is agreement for a team to be successful. They cannot agree with everything they do together. (...) We have different opinions, we have different ideas, we have different thoughts. Then you say, all right, we consider these different options, but for this particular situation, this is what we are going to do. And now the team is aligned towards moving in that direction. And if we don't communicate effectively, that alignment is lacking. (...)
The alignment comes from communication. Communication comes from collaboration, and collaboration comes from having the teams that are given that opportunity to dismantle all these barriers that prevent us from communication and be able to work together.
Tell us a story about the best class you ever taught?
The best class I have ever given, honestly, is never the one I thought about when I start or finish a class. When I'm teaching a group, I can get that feeling that these people are great, they are interactive, they are communicative, they listen, they participate, they are doing labs, they are great. And I also have teams that are indifferent or not participating, which is rather frustrating. But in all honesty, as much as anybody would love to have a team that is interacting and communicating, the best one I would say is the one that can show the results of the learning. And I'll give you an example of this. I had a team out in the UK called me and said we want you to come and do TDD training. And I was talking to their manager and I said “Why do you want to do TDD training?” He said that they want to improve what they do. Then, I recommended that he changes his method, when he told me it was costing him a million dollars.
And he said “Why would I not want to change things when you're losing a million dollars?” With respect, I explain if I'm walking on the road and a $10 bill flies away from my hand, with all respect, I'm not going to run behind the $10 because to me the $10 is an insignificant amount compared to the wealth I have for your company. My $10 is a million dollars. He wanted to know why they really want to do automated testing, and gave him the real reasoning. But instead, I said, ”if you give me two weeks, I will sit shoulder to shoulder and I will do pair programming to write automated tests with your team.”
I'm teaching them, but not traditionally. Let me stand up here and talk about this using slides, but sitting down and doing programming with your team. He said that's not what we called you for, but let me think about it and I'll get back to you. And a month went by, and he called me and said all right, we talked about it in my teams. We decided to give this a try. So why don't you come over, no official training, but do pairing, so you can teach us how to do automated testing on the software projects. So I went there, and I spent two weeks literally rotating and pairing with developers and doing automated testing on the project. And how did that go? Well, from the excitement point of view, I would say that was great. They were interactive, obviously they were challenging me, constantly questioning. We took really hard problems, and we're able to really redesign and write the test for it. But was it a success of a failure? So was it the best class, or was it the best training that I ever did? No.
But the AHA moment for me was six months later when I got an email from the manager saying that they realized I was in the UK for speaking at a conference. They ask me to come and spend half a day with their team. They were super excited to have an opportunity to see me again. They showed me the automated test they had done on their product, and I was blown away. That's an example of the best training I have ever done.
The most ineffective training is when teams show excitement and the minute I walk out of the building, they don’t incorporate any change.
Your final word for this interview?
My recommendation to developing software would be to be absolutely shameless. This is one of the recommendations I give both for junior developers and senior experienced developers. We work in a field where it's a process of learning every single day. Ideas lead us forward, but the ideas that we get to learn are the ones that are going to change the way we move in the future. So to be absolutely shameless, and if you ask me, one tipping point for me is when I started writing my books. Ask people to review your book. And it's a very humbling experience when they come back and point out so many things in every single chapter that need to be modified or improved or rewritten. And the amazing aspect of that is you come here with things you know, but you get to move forward with the things you can learn from others and learn with others. But that umbrella experience really comes from being willing to be shameless. If we are trying to be protective of what we know, it actually holds us back from becoming the better ourselves tomorrow.
So be shameless to ask for that feedback and say, I work with some amazing people who I respect a lot, but what really increased my respect for them is they would come down to the team and say, I implemented this, and I want you to review this and tell me what I can improve on this one. And when I hear that, I consider this person to be an expert. Now I know how this person became an expert by being willing to really listen to other people's ideas and to come down and say, I implemented this. I'm going to hold the fort and defend. It’s not a good solution to move forward, but to say, I implemented this, but I want you to tell me how I can improve it. You only come up winning in this type of situation. Because when you go to somebody and ask them to review and get feedback, they say, what you have done is great, that's a fantastic validation to your ideas. Or they say, here are the things you can change and improve that gives an opportunity for you to learn a few things, to do better in the future.
.png)
