The Benefits of Building Quality Software from the Start


Today’s guest, Sean Coates, Director of Software Engineering at KUDO, takes pride in doing software engineering the right way.

It’s the reason he became a boss. Before that, he had managers that were perfectly fine with rush jobs and cutting corners to meet a deadline.

Not Sean.

In this episode, he explains why using engineering best practices—design patterns, test-driven deployment, and pair programming, for example—enables you to scale faster and build stronger applications.

We discuss:

  • How KUDO enables live simultaneous interpretation in video conferencing
  • How AI and natural language processing might be applied to KUDO in the future
  • Why it pays to build quality software from the start
  • The difficulties of microservices
  • How to build and maintain an effective distributed team   

Want to hear more stories from high growth software companies? Subscribe to Application Modernization on Apple Podcasts, Spotify, or check out our website.

Listening on a desktop & can’t see the links? Just search for Application Modernization in your favorite podcast player.

You are listening to application modernization, a show that spotlights the forward thinking leaders of Highgro software companies. From scaling applications and accelerating time to market to avoiding expensive license and costs, we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it. Thanks for listening to the application modernization podcast presented by Shatousoft. I'm your host, Nick Mark Eli. Today we spoke to Sean Coates. He's the director of Software Engineering at Kudo. KUDA's a very timely offering to the market place. They do multilanguage translation through virtual meetings. Shawn will do a great job explaining what that looks like and how they've built their offering and how they're bridging the gap for those types of services in a pre, during and post pandemic world. So very interesting conversation. You also found a couple things to challenge some assumptions I had. So it is really great conversation. Hope you enjoy. Thanks to red at for continuing to sponsor the PODCAST. Hope you enjoy. Sean, thanks for joining the podcast today. All my pleasure. So for all of our listeners. Could you give us a, you know, an introduction, your role, your experience, your organization, you know, the kind of a biographical introduction for everybody. I'll give it a shot. My name is Sean Coates. I'm the director of engineering at Kudo. Kudo is a language services company that specializes in enabling video conferences and multiple languages through the use of live simultaneous interpretation. Then with a company about a year and prior to that I've worked with a variety of different financial technology companies, startups and small businesses, but I've really enjoyed my past year with the Kudo very cool. Thank you for that. So let's peel the onion a little bit on Kudo and what you're doing today. So basically, we have interpreted interpretive services and certain types of events. How is that handled in the past and how are you guys doing that differently today? Certainly so. Our clients are large multinational organizations in the public and private sector who have a need to hold meetings and several languages at once. Think activities at the UN as an example right where people from different countries are try to have a conversation together and the only way they can communicate is through interpreters and in fact Kudo was founded by a few people who used to work at the UN and in the old days there was a lot of technology involved. You would have an interpretation booth and microphones and it sets would wire to the interpreters in this booth and they would provide the interpretation services. And to make that meeting happen you would have to locate all these people physically in the same place where all this technology is possible. It was very difficult and challenging, not only from the technology but also from the logistics of getting everyone in the same place in the world. So Kudo decided to address that by the power of video conferencing and extending it beyond simple video conferencing but to enable language channels so that when our interpreters are connected with Kudos and Kudo meetings, they can provide their interpretation at the same time that the you know, the clads, are speaking and for the people who are listening, they can select which language they want to hear and thus they're not hearing all the languages at once, they're just hearing the language of their choice. So if it's a meeting in English, French, German,...

Spanish and they only want to hear the French. Well, they can sect French channel and they would hear the French interpreter and the people speaking French and they wouldn't hear the other voices and thus they'd be able to perfectly understand the meeting. So Kudo was very helpful for a lot of people. But when the pandemic hit, Kudo went from being very helpful to absolutely required, because suddenly meeting in person was no longer an option, right, so it became an essential service as rice, because we're still going to have meetings, we're still going to have the need for multiple languages. So I mean, governments didn't stop, although probably felt like that for a little bit, but it was, you know, it's really interesting. So, you know, I would think there's a significant amount of infrastructure or equipment that you would need on sites. So you guys basically eliminate a lot of that through your service. So you're not renting additional space or or booths. Your right, no travel cost and I guess right. Yeah, like to hold one of these meetings. Say You wanted to have an important meeting and the meeting was only three hours, but you had to fly people into one location, put them up in hotels, bring all the equipment there, get it installed, get all working. That one meeting could cost you tens of thousands of dollars in the old way round. Yeah, and so with Kudo meeting were able to really change all of that. And then about a year ago we decided to address a second problem. A lot of our clients didn't have their own interpreters and they needed the the services. So we had the technology, but they still needed the services. So we created Kudo marketplace, and this is a marketplace for interpreters that our clients can search for the interpreters they need and attach them to their meetings. And independent interpreters can sign up for Kudo marketplace and register, become certified right and be made available. And so it's a supplying meets demand te scenario. Gosh, it's so basically, it's funny. We have a we have a market place for everything. Now, do you want to run a can do on the beach? Do you need an interpreter that can speak French? Right? It's pretty amasy and how we've become. It's, you know, and as a service type economy that we're in. You know, like you just you need it, you can get it all, you can get your meeting and you can also get your interpreter and you can do it with one or two clicks and you're good to go. I assume that's how a customer signs up. Right, let is go. I'll have this and I'll have one of these and I'll have one of these, and it's that easy. Right. It's getting there. It hasn't always been that easy. There's still the client relationship in the sales process. It's not the cheapest product of the world, I'll be honest, sure, but it is still much cheaper than doing it in person. Now that's you know, that's interesting because you know, in our business, we we have that conversation with customers all the time. It's you know, there's there's this program this programmatic approach, where we can help you where you want to go or you can go build your own team. So in your case, you don't your customers don't need to have an interpreter on staff because they can get one relatively on demand and not have to worry about all the meeting logistics and all that tedious stuff. You guys are taking care of that. For them. Yeah, like they don't have to pay the interpreters directly, they just pay us a master contract with them. Right, that's very, very cool. So shifting yours slightly to the, I guess, the engineering inside. What are some what are some concepts that you've run with the Kudos since you've been there? Like, I assume you're probably cloud first. That would be a guess, but tell me, tell me if I'm wrong. It's definitely cloud first. We built our applications on aws so that we can make them available to everyone and...

...because of GDPR and other concerns, we've had to address data location issues. Sure you know, like where do you record? Where do you keep the recordings of a Kudo meeting? Right, so that that caused us to host in different regions with aws and lever to that feature of a tops because there's a locality, I guess, especially in Europe, right, there a challenge around that where that data lives. Even though it just might be a conversation, GDP ours become a right there. Well, on the surface that feels like just a conversation, but these are very important conversations and some of them are a very sensitive nature. Sure, now, that's that's a fair point. So where lives very, very important. ABS is pretty good at that from a billability zones and regions and things like that. Any other specific things around how you guys choose to build a Kudo that you know might be unique or leading edge that you can you can share and lightness on? Well, our team has always been globally distributed. So although Kudo is headquartered in New York and there is a little office there in New York, most of the hundred and sixty plus employees of Kudo don't go there. You know, we're all working remotely. We're all over the world. I think it's over twenty different countries now, and so my team, I have developers and engineers in nine different countries. So you're working across multiple time zones. It's an interesting thing, but you know, it means you can recruit from a larger pool of talent. Sure, but you have to you have to be a lot very particular about who who you choose to join your team. Right now, I would bet the analysis around that is I just think about trying to build a team in the southeast. It's it's got its own set of measurements and you know, things were looking for, culture items. Obviously, technical skill. How you know, one of the strengths around communication, things like that. How do you how do you? How do you broach that challenge with a global team? Well, for me, when I'm looking at people, I look at several factors. Cultural fit is a big one, right, people who have to value collaboration as one of their core values, because we really don't want people working alone. Maybe it's ibrotic being distributed team. You know, letn't working alone, but we want people to work together as a team, collaborative, with a lot of live conversations through video calls and slack and so forth, because it's only as a group that we really succeed. You know, a mistake that one person misses can be caught by other people who are also watching and it greatly increases the quality of row code. Right, Gosh, there any specific development paradigms that you guys use? Like you do a lot of parent programming. You use any other types of framework? That's interesting. Well, we, yeah, we believe impairing, not hundred percent, but you know, whenever, whenever it gets challenging, we want to use that as one of our tools to like solve problems. Sure, we also believe in test driven development, which means, you know, writing your test first, but more than that, it means taking the requirements and thinking in advance what your dependencies are, you know, because when you write code that's meant to be testable from the get go, if forces you to write loosely coupled code, now that makes sense. Yeah, there's a well to just having requirements make sense and I know sometimes that's a challenge. Yeah, and I certainly spend a lot of time on requirements. So it's not just the engineers, but I spent a lot of time with product people who write you know, go back and forth and like what's the best way we can build this to create an awesome some experience for the customer? Yeah,...

I actually think that can be one of the harder parts being you know, I'm not an engineer, so, but building requirements for programmatic things we're doing for customers or, you know, literal programs that we're doing for customers. That is hard, right, you got to you got to ask the customer what do they need? And sometimes you're not, you know, you're not just inner out. Yes, you're just you're thinking. Often the customer doesn't know what they need. Right, right, you have to draw it out of them. So I would imagine with Kudo you're in a similar position. All the time. You're going, what are some of the features that would be really impactful for a customer, and your kind of dreaming on their behalf. Sometimes. Right. Well, we look when you're building a marketplace for interpreters, where and done has existed before. A customer doesn't know what they want. They didn't even know that they needed this. All they know is they want to have a multilingual meeting. Right, yeah, now, yeah, and then there's the whole burden of what sales and marketing around that they're gonna have to go. Okay, and now we have this thing. So we have the interpreters for you for your your multilingual meeting. But now we need to let you know about it. Right, not not just building it, but also being able to effectively put it out to market. And so we use fig mail a lot for this, okay, because it makes beautiful diagrams for what the product could look like, and so we'll create like mockups of the web pages and everything. So before we're writing any lines of code, we have all of these pictures of how the application could look and the developers can say here's how we could build it this way and then we'll show it to business people to say here just how it could look to the customers, to get all the feedback of hussibly can right. Did you always? Did you always always do it that way, or was that a bit of a revelation? Like you know, we should, we should kind of mock this this Ui out and see how it feels. But I think you as one of the hardest, the hardest things, or maybe one of the last things. Sometimes when you have a you know, a bunch of developers, you like you know, we're building out requirements were, we're making it happen. You, I and you x tend to be. Can Be, can be left behind? Was that? Was that your experience? Or it was an evolutionary thing? It started out we had mockups, but they were very plain teesy, like wire frames. Right. Why? Our friends, yeah, very livid and of our time. People keep coming to US says, I know of a better tool, I know of a better tool. Okay, let's see it right and that led us to Figma and then we found people who could use pigma better than other people, right. Gotcha. Yeah, I would challenge anyone if you know why our forem or website. You know, if you're just, let's say you're not a technical person, go through that process so you can get a feel for what putting requirements together are and how you align all the people that need to be a part of it, because, you know, you could just be selling watches. That's not very technical, but that's also still a pain. To be able to get that concise layout and how customer interacts is something it's pretty difficult and it's it's never one and done. It's a costly evolving thing, right. You know. How does your team go about updates? Do you guys update very regularly or you on a you know, but you know, one end you've got netflix updating, you know, pushing an update every two seconds or something, right, and then you know some people might be once a year. How does that look like for you guys? Well, right now we're more in the traditional scram method, using three weeks sprints. It would be faster, but we have a very long testing cycle. Gotcha. Okay, so we actually put our application process through, you know, a round of regression tests and quality assurance that we're trying to automate and as we get it more automated, that regression cycle will shorten in time and we'll be able to reduce our sprint down the like three weeks from to two weeks, right or if we get better at it, we'll get to the point where we can do it...

...even faster. And Look at models like Netflix where they're releasing code on demand like four times a day. That's awesome for them, but we're not there yet. You know, we're a small company in comparison. Yeah, I think it is. I think it is four times a day. I think I was that stat was actually Amazon. So like every two or three seconds they're releasing something against the service. Somebody around here runs around talks about that all the time. I'm like, well, they're Amazon, so they can do that. So we're talking about maybe looking around the corner, right. So, like you're in a very, very interesting space. Lots of new technologies, technology concepts are out there in the marketplace. Like everyone's run around talking about, you know, machine learning and AI and natural language processing. How do you see some of those being applied to what you might do? You know, Kudo in the future. Well, it's an amazing it is is a viable that's the other thing that's not there yet, but it is an amazing set of technologies and we have a research team on staff who continues to push the bubble on that stuff. We have built a couple of tools already that assist the interpreter in their duties. One is the interpreter assist, which creates glossaries based on documents provided by the client in preparation for a meeting. The AI engine will scan the documets, find the important keywords in the documents, automatically translate them and give them to the interpreter as a here's a glossary for a warm up for you. Gotch another product we have is the spadometer, which is pretty cool. It's a little meter that, in real time, is listening to what you're saying, breaking it up into words and word chunks and measuring your talking speed and basically flagging you yellow to red if you're talking too fast, because if you talk too fast the interpreters can't keep up with you. Okay, so that that that goes to the input right the person given the primary messaging, so that they know this is the cadence I should be talking at right so that, in turn, burs can have accuracy and keep up. Really is probably the key R I am and, as you know, technology advances with automatic speech recognition natural language processing. Someday in the future will be able to have more tools to assist interpreters or potentially for people who don't have the most critical of meetings and automated interpreter. Gosh, that's maybe a part of the platform. So if I was hosting a meeting with ten people and it was an internal staff meeting, but I have folks in another probable world and maybe their primary language is Spanish, not I can run that meeting. I could send them output of that like. That's that's kind of what you're talking about. I guess that's you know, that's another possibility. We're also looking at things where we could do interpretation on recordings, but a lot of a lot of it is technology that's still evolving right today. It's very important to us that everyone completely understands what is being heard and you really can't break language barriers unless you have that Certi fight interpreter that you have a very high level of confidence that they're giving you the right message, that one word didn't get horredleously replaced with the wrong word because the machine learning robot, you know, made it made an error. Right, robots making up its own its own words. Now that make sense. So so, basically, there could be cool enhancements that come along the way in your space but it's primarily driven by humans at the end of the day. Yeah, it's probably going to be like that for maybe forever, because, well, I don't about forever, but for the next few years. Yes, maybe in our lifetime well. But, like I said, technology is very exciting. It continues to evolve and it gets better every year and it wouldn't surprise me that, you know, maybe several years down the road. I don't know if it's five years, ten years or twenty, but you will...

...get to the point where, like automated interpretation becomes viable very in some cases, right, not not every case. So always like to ask our guests, you know, what's an interesting lesson learned, something you can share, could be recurrent, might not even be Kudo, just something you learned along the way that would be helpful to and sparring technologist or someone who's very interested in the space and you know, creating products and offerings that help customers. Well, for me, I was always excited about getting the opportunity to do software engineering the right way, and the only way I could do that was if I became the boss. That's would let me to management, because I had a few managers that just wanted to rush things through and the deadlines more important than the quality, and we always paid for it afterwards and we would be fixing bugs the next three years based on a few poor decisions. And my mind, people should focus on doing software engineering the right way. They should focus on quality, use design patterns, test driven development, solid principles. Pairing all of these great things, these advanced topics, and you will be a level above all the other engineers. Gotcha. So so is your experience previously where things didn't happen the way you wished to implementing tools and frameworks and things that you thought would develop better software in the end. And it pays evidence. When you build quality software, you're able to add features and functionality adding an increasingly faster pace as time goes on. When you don't care about quality, adding new features actually gets slower as time goes on, because everything you add breaks five other things. Right, too many dependencies, you know. So I so assume you guys are building code a microservice approach. Don't do I guess could be wrong. Yeah, we're not. Now really, you just you just seemed like microservice approach. microservices are interesting, but they do require you to adopt a nightmare from by infrastructure point of view. Right, interest, okay, because next thing you know you expand on that. Sure, that's interesting. Well, I mean next thing you know you have a hundred different deployments with a hundred different repose, all of which have similar dependencies and the dependencies may or may not be managed the same level, and that all talking to each other. You just have a lump. Are Ways that the whole collective machine can break because of all those inner connections and redundant code. So I'd like to have a small set of services, but I wouldn't call them micro, right, got it. Okay, like I have that a medication service where everything around authentication lives, log and user profiles, organizations. But it's so it's not micro in any sense the word, but it covers everything that's around athecication. So you can you can still have too much of a of one thing, I guess. So, while the whole market is very focused on modernizing applications and you know you go microservice, microservice, microservice, what you're saying is that's fine, but too much is too much at times. So you got to be thoughtful about yeah, it's maybe more I'm marrying. If every little thing is its own serpace service, you'll have a very chatty application that spends most of its time talking to itself over the network and it'll have hundreds of points of failure. One little piece goes wrong and the whole thing's down. Yeah, all the sudden that sounds like a bad idea. It's interesting. Yeah, I mean it's why people kind of get lost to microservices unless they have, you know, really powerful networks. You See, facebook did it very well, but their facebook. Right, I mean right, you know that if you throw tenzero developers at something, you can fix anything. Right. Yes, the scale of engineering,...

...resourcing people in money, maybe not, maybe not this week. In the past. We kind of touched on this already, but you know, you probably, I've a feeling you probably have a couple of other takeaways around this. So you know your team's distributed. That's got sound set of challenges and advantages. What some what's some other kind of gotos around building great teams that you think are our core to having one in maintaining yeah, well, first you have to decide what are your team values going to be? What are the things that are most important to you? Like I go for humility, openness and collaboration as my big three, because I don't like working with people with big Egos. They run people along the way. I don't like working in organizations that are full of secrets, so I push open this and collaboration. Is really how software engineerering works, and you need people who are team players. So you find people who are good at those and then you find people who have long resumes with proof of prior experience. And for us, we recruit globally so we have a bigger pool to draw upon. It's always a lot more challenging when you say here's my requirements and I want everyone to be available in the South Florida area. It's like something. Your Pool of talent is a lot smaller, you know. Yeah, absolutely. I mean that's funny. That's how that's how everybody used to build teams as of three years ago. Yeah, now our HQ's in Atlanta. We'd prefer you to be in Atlanta. All the sudden I'm like, yeah, hundre an engineer in Texas? Why not? Why not? It's only a couple hours, you know, it's great. So it's you know, it's funny how the pandemic is really changed. You know, I'm sure for your organization it's been a really positive change in necessity around the services you provide, but it's forced a lot of, you know, more traditional businesses to go. How do I? How do I morph into what's next? Right, you know, we have towers in Atlanta that used to be filled with people and that no one's there nowther have bapty, right, yeah, it's right. It's great, fright. And you know what's unfortunate about it is working remotely is not for everybody, and so totally agree. What do you do with those people who are not good working remotely? Right, they need a place to go to or maybe, yeah, don't have the capability. I have a young family. Especially during the early part of the pandemic they were home because school was digital. I'm not getting anything done at home. Luckily, our whole team was at home. You know, worked out for them and I just came to the office was the only one here. kind of worked out. So it's you know, everybody's needs are different. I've had to learn how to work remote. I love working with people, I love being collaborative. We are, you know, predominantly back in the office at this time and the you know, I try to I try to work from home on Fridays. That requires a lot of structure for me because I've never done it right. I've just never had that. So I had to learn how to be efficient. Yeah, which, you know, being distracted was never a big problem, but, you know, just having the comforts of being able to like lock in and, you know, do for hours a good work and have launched and do some more work. Right. So it's a different thing, right. Yeah, it's like how do you get to know your coworkers on a personal level when they're not there the same room with you? That's it's a skill that people work on right, right now, exactly, and you know, that's really helped me figure out how to add to our team from places where we don't live, you know. So I've engineer and Florida and team member in Tennessee and you know, it's helped us really figure out how to collaborate together in a way that's meaningful. It's probably a shame it took the pandemic to do that, but we're better for it. I think we'll see. So far, so good, though. All right,...

...well, Sean, thank you so much for your time. Thanks for sharing about your organization and breaking up a couple of assumptions that I had. That was great. So really enjoyed the conversation. Thanks for coming on the PODCAST. Absolutely I was happy to be here. Application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and Coupernetti's technologies. Thanks for listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and if you use apple podcasts, do us a favor and leave a quick rating by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (28)