Frank Trainer on SOLID architecture, Technical Excellence and Development as a Team Sport

Transcript

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down across distance with Frank Trainer. Frank, welcome. Thanks for taking the time to talk to us today.

Frank Trainer: Thanks for having me.

Shane Hastie: Frank, you and I met for the first time today. You have a pretty interesting story. Do you want to tell us a little bit about who you are and who Saggezza is?

Introductions [00:40]

Frank Trainer: Sure. So I am the vice president of process and delivery at Saggezza and in charge of the engineering practice, which is all good and fun. But what I'll tell you is that I came about all of this in a very unusual way perhaps. I graduated from college with a degree in restaurant management, and then in my 20s, I opened up six pizza delivery places. And I learned what I didn't want to do for a living. So I left there and I said, "Oh, well, maybe I just want to make a lot of money." And I got a job as a stockbroker, and I worked for five years as a stockbroker and I made a lot of money.

And you know what I found is that the people that I was working with who were stockbrokers with me, some of them were really good at it and they excelled, and I struggled. I could do the job but I wasn't passionate about it and I didn't love it, and so I began a journey to discover what it is that I was good at. And I took some classes at the local community college and discovered computer programming. I took the Myers-Briggs test and whatnot, found what I loved to do and then pursued that as a career, got hired on, became an independent consultant, went to grad school, got a master's degree and so on. So that's my journey. Along the way, I worked for some very large companies. I worked, before Saggezza at a company with 120,000 employees. It was very easy to get lost in all of that.

The things that I was passionate about, it was really hard for me to do anything with them there. So I came to Saggezza because an opportunity came up for me to pursue my passion and I grabbed it. I've not regretted it ever since, it's been fantastic. So there you go. That's maybe more of a story than you wanted.

Shane Hastie: No, that's an interesting start. We actually do share the genesis in the restaurant industry and I can totally understand not wanting to, in my case, make more hamburgers.

Frank Trainer: There you go.

Shane Hastie: So Saggezza, global, horrible term, outsourcing organization.

Frank Trainer: To a large degree, it definitely started out that way. The teams are mostly located in India. We have some teams in the UK and in the United States as well, and it was originally outsourcing. I can tell you that it is now very much taking control of projects and delivering on things for clients. It has advanced from that. We now take ownership of a lot of the processes that we work in, and it's not just staff log for instance. So it is an interesting size for a company, there's about 750 people all told, which is a place where you can make your mark and make a difference and be seen and heard, so fabulous opportunity.

Shane Hastie: When we were chatting earlier, one of the things that you touched on is how the organization deals with people in different locations. This global distribution is becoming more and more the norm today. Distributed teams, remote teams are suddenly the thing because of COVID in many cases. But when we looked at it in the InfoQ trends report earlier this year, which we were looking at in November last year, we found that remote was a thing. Remote has become much more of a thing. Distributed is definitely a thing. What's difficult and what's different?

Having a remote first culture [03:33]

Frank Trainer: It's interesting you say that because we have been working in a distributed way now for years, and because of the issues that we encounter in Southeast Asia where people might have trouble getting into work, or they might have long hours and need to work remotely, there was always the option for someone to work from home. It was always part of the process, and the way that the teams function is such a way that when the pandemic came around, we were really, I think, surprised at how little impact it had on our ability to continue to deliver and do our jobs.

Using BDD & Gerkin to Communicate with Product Owners and Customers [04:01]

Frank Trainer: Everyone already had laptops and they took them home with them, and they had internet connections and they were able to do their job because they were doing that anyway. And the way that the teams talk to each other, the way that they communicate with the business, we use something called acceptance test driven development and Gherkin syntax, so we get true/false statements from the product owners. And what we ask them to do is to tell us, what are you going to do to test what we've done and tell us if it worked or not?

Frank Trainer: We asked them that upfront because we don't want to be doing any work where they don't know how they're going to tell us if it was good or not. So that acceptance test driven stuff leads to these given when, then true/false statements. And these statements allow us to move conversation very early on to questions that the teams might have, and location doesn't really interfere with that. We do have, typically we did before the coronavirus, we did have a person onsite with the client, and they were able to have face-to-face conversation and they were able to get ahead of some things and take care of some of the time differences. We still have that person here. However, they are obviously not face-to-face with them anymore, but we have Zoom calls and we have chats and all the rest and we're able to continue working just fine.

Shane Hastie: ATDD, Gherkin, these are technical things we've known about for a long time, except test driven development is one of the practices from extreme programming, which goes back to the late 1990s. But you're talking about taking this in conversations with customers and product owners and so forth. How does that translate?

Frank Trainer: It turns out that is almost universally accepted and they're excited about it. Because too often, there's a disconnect between the business and IT, and the business makes requests of IT and then IT fails to deliver what the business thought they'd asked for. And so this idea of getting in front of them and showing your work often, and assuming, and giving everyone permission to be wrong, product owner and the business they're allowed to be wrong, team is allowed to be wrong. We're just going to show our work, we're going to fail fast and we are going to iterate, think through things.

Frank Traine: I know there's this idea of a scrum, and we do have these ideas of sprints, but we very much accept radical change if they want to give it to us at any point. We are extremely agile in that way. It is a strategic advantage for our clients. I one time had a customer who asked me for something and the team had spent two sprints on working on it, and we showed it to him and he said, "You know what? I realized is that is what I asked for, but it isn't at all what I want now. I want something different." And he showed it to me. And at this time, we were fairly new to this process. The team I was working with had only been doing it for a couple of sprints.

Strong technical practices make adaptation possible [06:40]

Frank Trainer: And so I went to them and I said, "Okay, we've had a fairly radical request for change from the product owner, and this is what he wants now." And the team was not thrilled about it. I did get some initial pushback and they were like, "Oh, I can't believe it." But what I asked them to do was to just spend the day and see what they could do. Now, I should back this up by saying that we'd asked them to write SOLID principle code, single responsibility, very small objects. The code that these teams are writing, when you open it up, if you open up an object, you can see the entire object on the screen. You don't need to scroll, and it's usually not necessary to document it because you can tell what it's doing. It has a single reason to change.

Frank Trainer: Anyway, because we're building these small objects, what the team found was that almost everything they needed to do was to just rearrange them. So I believe at that point, we had a state pattern and they just changed some points and called things in different orders and added a few things, and I came back the next day and I was a little bit apprehensive to ask them, how had it gone? And they said, "Oh, we're done." That was an aha moment for them. It really sealed the deal for that particular group on what we were doing.

Shane Hastie: That's one way of bridging communication barriers. What else? What gets in the way of effective communication around the globe?

Bridging cultural differences [07:50]

Frank Trainer: It's interesting the different cultures we encounter because obviously, our teams in the UK and in India come at it from very different perspectives. And what I find is that in India particularly, it's a very hierarchical structure and the people that we're working with oftentimes feel like they need permission to speak up, and what we're trying to do is to develop teams where everyone is an important member of the team. Our idea is that if you're writing code that goes into production, you are the most important people on the team, and that we want to make sure that we hear everyone's voices, and that they do not feel like they don't have enough time in to speak, they don't have permission or they're going to upset someone. And so that takes a little bit of time. However, we definitely emphasize it.

We explain to them how important it is for our success to make sure that we are hearing everyone's viewpoint, and the more different viewpoints we can get, the more success we're likely to have. And so just seeing it now, I'll tell you the initial change was a challenge. At one point, one of my clients told me he thought I was probably the most unpopular guy in the building because I was trying to effect change, and that can be very difficult. But there is a moment where the teams get it, and when they do, then it's gotten and you have established a culture that allows you to proceed forward with it. So that kind of thing, definitely, now we don't have any issue with it. When we bring people in, we identify them when we're interviewing them. So we're looking for people who have great initiative, are very logical in their thinking, want to work as a team and be successful and are open to new ideas. These are the kind of people that we're trying to bring in.

The downside of experience [09:19]

Frank Trainer: And we teach them how to do test driven development and how to use SOLID principles and how to work with the team. It's interesting to me that the people who have the hardest time with this are the people with the most experience. In fact, the people who are mostly successful with this right away are the kids straight out of college, who haven't learned a lot of bad habits along the way. I can tell you, I'm going to be 56 in a couple months and I learned a lot of bad habits. And it took me a solid six months to wrap my head around all of this when I was first learning it. It was hard. These kids straight out of college, this is not an issue with them at all.

Frank Trainer: In fact, I had an interesting situation a few years ago in India where I was talking to the CIO of one of our clients, and they were trying to find a bunch of people who had 10 years experience and a whole bunch of things that we could check off on the resume. And they were having trouble finding these people because frankly, they probably don't exist or they couldn't afford them. And so we had a conversation and it was, let's try something, let's have an experiment. How about I take 10 kids straight out of college, never had a job, straight. And I spend three months, spend an hour a day for three months working with them, and I teach them to be a self-managing team that does test driven development, SOLID principles, all of the stuff we've talked about, about Gherkin syntax and the rest. And then I give them to you and let's see how it goes. And he agreed to try it.

Frank Trainer: We did that. We turned it over, they were wildly successful. The team is still there functioning very nicely. So these things that we're talking about, like you said, some of them are very old. They're 20 years old, but the thing that's different is that we are doing something that I think most Indian developers aren't experiencing, which is we are empowering them and we are listening to them and we are telling them that they are a key for our success.

Frank Trainer: Unfortunately, my experience has been that many times, because they get paid less, people think that their ability is less. But in fact, what I've found is that they go through such a crucible in their education system trying to get into good universities and trying to learn how to be programmers, and by the time they arrive at our door, they are highly talented and capable and motivated people and they just need to be acknowledged as that and given an opportunity to show us what they can do.

Shane Hastie: What does this mean for the 10 times developer? Or you told me the story of the six times developer.

The myth of the 10x developer [11:35]

Frank Trainer: I did have a guy who, on his own annual review, he wrote down that he was six times better than anyone else on his team. And my response was that he should move on, that you should find another job. Because what we're playing is a team sport, and if you're six times better than anyone else in your team, you have a job and your job is to help the other people on your team be better, and it's not to revel in how much better you are than them. And that attitude is not one that's going to be productive. We do not want any Supermen. We are looking for our team members to identify the smallest, simplest solutions to our problems. I ask them to do that, to identify the smallest simplest choice. And then if they choose to, they can move away from it, they can refactor out of the simplest choice, but I want them to identify it first. Sometimes, it's the right answer.

And when they do choose to refactor, we still expect them to follow single responsibility and all of the SOLID principles. We still expect them to come up with a good solution, but there are three questions that we ask of all of our developers. When you do a code review with us, first off, we just accept that there's no perfect code, that we aren't writing perfect code. It's not a goal of ours, it's not particularly valuable. What we do is write imperfect code.

There is no perfect code – self-awareness is what makes the difference [12:49]

Frank Trainer: If we're going to admit that we're writing imperfect code, it's very important that we understand what's wrong with our code. And that's the first question we ask the developers, is what's wrong with your code? And we have a conversation about that, and we expect them to know it and to be able to have answers for that. The second question that we ask is how would you fix it? If we had to, how would you get out of this code smell that we have? And the third thing that we do is talk about when would you fix it? What would cause you to want to go in and make that change?

Frank Trainer: And if they can answer those three questions, then virtually all of the code that they've written will be acceptable to us because it means that they have gone out and they have chosen their defect. It's not something that's going to show up at two o'clock in the morning on Saturday with a phone call. It's something that we are aware of and have accepted.

Shane Hastie: That's a radically different approach to code reviews. In my experience anyway, code review is, "I don't like the way you wrote this code. It's sloppy or it doesn't conform with my personal opinion of how you should be indenting," or whatever. How do you get that sort of thinking into the team?

Making code reviews effective [13:53]

Frank Trainer: The answer is that we try to drive it down into small enough simplest things, like I said, that you can look on the screen and see the entire object on the screen. And so we want to make sure our objects are not doing very much. And if they're not doing very much, and they meet the requirement for the tests that we've written ahead of time, because we do TDD, and they pass those tests and you can have a conversation about why you chose what you did, then it is hard-pressed for someone to tell me that it is not formatted properly or anything like that. I mean, if there is some way that it is confusing to the team, then they will address that individually. But the vast majority of the time, there's just not enough code on the screen for that to really matter. We are talking about very small objects.

Shane Hastie: What does this mean in terms of choosing approaches and the way teams work? We hear a lot about giving people freedom of choice in their approach versus coming up with organizational standards or guidelines. Where do you fall on that spectrum?

Balancing autonomy and defined process [14:55]

Frank Trainer: I fall all over that spectrum. So the answer is that, of course, we have process, and people might push back on the idea that we've given teams process. But I need these teams, we need these teams to be able to work together. So there's a lot of conversation about how do you get multiple teams to all work together in a scrum? And that's a valid point, and there's SAFe and LESS and all the rest of it. What we tend to do here is we ask that all the teams work in the same general framework. So we ask them to do TDD and to do SOLID. We ask them to do acceptance test driven development. We ask them to solve small, simple problems. We ask them to break the stories down in such a way that any member of the team could take it and do work on it.

We ask them to fail fast. We have this idea of bad news is the most important news, and you share that bad news early and often. We have open conversations in the team about how we improve. We have all those things, and those are, if you want to call it that, those are requirements. But the ownership of the technical solution is not. When you pass a test, a test that you wrote, and you choose to refactor it, that's you. How you choose to express your ability and how you wish to express your thinking and your work as a member of a team is done there. Your individuality, to a large degree, is your expression of the code inside the framework that we work in.

Shane Hastie: How do you make choices about the sort of overall framework and approach? There are many brands out there today. Why would you choose one approach over another?

Write code for your teammates [16:23]

We tend to work on the idea that we're writing the most testable, maintainable software that we possibly can, and that is our goal. We want to make sure that if a phone call comes in Saturday at two o'clock in the morning and someone has to pick it up and answer it and they've not worked on the code, they can go back to bed at 2:05. We are writing our code, not for us. We're writing it for our teammates. So that is the ultimate idea behind it, and we do this because it's good for our client, but also because it protects us as a company. We want to make sure that we are not creating code fires. We want to make sure that when we leave a job, we have left them with low cost to maintain, high quality and the desire, frankly, to work with us again.

Frank Trainer: And so those choices are choices that are made for the good of the company, and I cannot have a team making choices that would interfere with that. So that framework exists in that regard. And what I've generally found is that it is not nearly the burden that you would think it is. I hear people describe organizing software developers like herding cats, but in fact, these teams, they work extremely well together, they are able to express their individuality and their capability in ways that show us how small and simple they can be, and their understanding of the language and particularly smells, code smells and technical debt and what the impact of that will be, they express their knowledge and ability that way. In fact, what I find is that people are really excited to work like this. Our turnover rate in the IT industry is exceptionally low. It might be 5% turnover. People do not leave this situation. They are excited to be there.

Shane Hastie: What's happened, given that we're in the midst of COVID-19, what impact has that had on your organization, your customers, your teams?

The impact of COVID-19 on the teams [18:21]

Frank Trainer: The answer is very little overall. The teams are able to continue to function this way. The cost for us I would say, COVID, the most impact it's had is that it has solidified our relationships with our clients, because it is far harder for a competitor to come in and try to dislodge us in this environment than it would have been beforehand. They can't really get personal time and face-to-face meetings, so in that regard, it's been good. The downside is that if we want to grow and expand it, it becomes more challenging. And we've seen companies be more cash strict, that the opportunity to do new things has been impacted as people are uncertain, particularly in the United States, about the direction of all of this and what it will mean.

Frank Trainer: On an operational level, very little impact at all. On a idea of growing and expanding and doing new work, it has impacted us.

Shane Hastie: And to wrap things up, advice for others. If they want to get this sort of team collaboration, I loved the questions from the code reviews, but people that want to try and learn from what you've been doing, what's the advice for the young player?

The role of a manager is facilitating your teams’ success [19:25]

Frank Trainer: What I would tell you is that if you find yourself in a position as an IT manager in any way, that you need to understand that your job is not anything other than facilitating your team's success and that I describe my job like this. I say that I take credit for the hard work of many very smart people, because that's what I do, and you need to let people be excellent. There's a lot of really, really good capable people, and they want to excel at their job, and you need to find them and then let them do it.

Shane Hastie: Frank, thank you very much. If people want to continue the conversation, where did they find you?

Frank Trainer: Well, you can find me on LinkedIn. I am also available at frank.trainer@saggezza.com, and feel free to send me an email. I'm happy to have a conversation.

Shane Hastie: Thank you so much.

Frank Trainer: Thank you.

Mentioned

• Saggezza
• SOLID architecture principles