Improving Software Development & Overcoming Modernization Challenges w/ Michael McCormick


Though the platforms have changed, many of the same application challenges still exist. Namely, finding alignment between the people who build the applications and the people who own and operate the platforms.

In this episode, Michael McCormick, Vice President of Technology at Artium, shares his perspective on these age-old challenges and provides advice on how to make modernization projects more effective.

We discuss:

  • The services offered by Artium
  • The practice of extreme programming
  • Lessons learned from multiple modernization projects
  • Tips for building a pipeline of exceptional talent 

Resources mentioned during the podcast:

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. For listening to the application modernization podcast. I'm your host, Nick Mark Reli. Today we spoke to Mike McCormick of artum. He's the VP of technology. They help customers design new new applications, apply, you know, new techniques and how they develop software, take a legacy applications and help modernize them for the future. Very, very focused on that. We had a really great conversation about teams and software development and great customer story. So, you know, enjoy this. Thanks to red hat for continuing to support the application modernization podcast and hope you really enjoy this. Hey, Mike, Thanks for joining us today. Excited to talk to you. Yes, thank you for having me on. I'm excited to chat good deal. So tell me, you know, just for our audience, you know, for the podcast we like to talk about stories around customers and their journey to application modernization. How you know you're off rains for your organization may help them get there. Why don't you give us a little background on your organization? Oh sure, yeah, so I work for a company called artium and we've got a big focus on kind of the mastery or the craft of software development and we work with customers in a professional service capacity in a couple different ways, and we build some internal software right it as well. And so the largest probably portion of our business by people part of an application new development group that we call technology labs, and so it's professional services, you know, helping folks build software. We work kind of anywhere in the life cycle of software might be sort of net new application development. We work with a lot of startups that are sort of in that ABC funding range right where they're working to either find product market fit or they're starting the scaling process because they have the type by the tail as or. And we work with folks, you know, Doing Modernizations as well. So you know, hey, we've got this old software that's quart or business and we need to figure out what to do next, right like we want to bring it forward and make it more useful. So our technology labs, teams work using a kind of combination of what I would call sort of like xp by default, right, like all of the all of the principles of extreme programming. Or there's things you would typically find in our organization test grim and development, you know, continuus, integration, etc. And then, you know, from a product management and design perspective, we typically kind of follow things like, you know, lean startup style product management perspective, right, like lean pridization, the backlog or you might call a dual track agile. From product design, we do a lot of user center design as we approach what we're up to. And so, you know, most of our engagements from technology labs look like some combination of engineers, product managers, designers working with our customers to build software collaboratively, you know, often in the trenches with customers working alongside of us. And then we also have what we call talent labs. So talent labs it is US looking at. You know, how we have hired technologists over the years to do the kind of work that we want to do and and focus on craft, and a lot of our customers have asked that over time as well. And so our technology labs team is both who we use to help do our sorry, our talent labs team is. So we used to help do internal hiring for us, but also external hiring, work with customers as part of the process of recruiting talent to their organizations. And then I mention we're building some software. We started to build software around the software development life cycle and how people collaborate in and so that's not launched publicly yet, but we're working on it inter got. Okay, so you're you guys are doing a lot of stuff all the same time. Yeah, that's keeping pretty right. Multi Facet of business for sure, right, right. So interesting. Oh, I...

...want to circle back on the talent labs piece because we actually do something similar here. So it would be interesting to talk through that. What is is there a unique qualifier for your customers when they come to you, like, like what types of customers fund did you get? Are you guys strong in a specific industry or is it really just for solving for what they're trying to do from Software Development Perspective? Any trends there? Yeah, it's definitely solving what they're trying to do from a software development perspective, right, and so it kind of depends on where that organization is and there their maturity of the perspective right. Like my mental model for it is sort of you have start ups who might be thinking as software as foundational for what they're doing. It's core of the business and how we do it right. Maybe software is not the only thing they release in their product, but it's absolutely a piece of the product. It's inseparable from the product itself. Those folks, when they come to us, we're usually working with them in capacities of Hey, it's where we're either trying to realize our application. You know it's it's it's in our heads. It's in we know the markets there. We want to we know how to do it. Help US use tools to to start to realize it and software and bring it forward and Testin. So folks that were working with in that sort of like you know, seed or a round of funding. We're definitely doing that kind of zero to one motion with them. And those folks there, they know we show up with technologists, so they're showing up with like clarity on what it is they're after. What is that market? How do we achieve at things like that, and we help kind of take those those their understanding of what they're trying to build and realize it. The folks that are sort of in the B Toc funding range like usually with those companies, what we're doing is we're helping them scale their their products their processes as well. Right. So when you're when you're growing like crazy from a headcount perspective, how do we, you know, get our folks oriented around continuing to move fast? We're going into a phase where it's really easy to go from being able to move fast all the time too there's there's so much happening around as so many new people, things like that, that we are ability to really software starting to slow down. So a lot of our customers in that range of kind of notice that they want to make improvements there, you know, either in the way that the people are transacting around software or and or how they build it, you know, more from a technical perspective as well. And then for a lot of our enterprise customers, and many of our enterprise customers are looking at parts of their own maturity where they already have a product in place. They may not actually be thinking of software as foundational to that product because the product may have come well before it and so well before the popularity of software. I would say so some of that crew is sort of looking at the idea that, hey, we have software, it's in support of what we're doing. We're transitioning our business to to think about that more or use it more, and so they could be in any sort of stage of you know, hey, we're trying to think about, you know, what you might call more like transformation, where we're trying to think more software first. You know how much that that work? What's the relationship between business and technology to kind of make that happen? How do we break down structures of we currently have that aren't really helping that? Or they maybe, you know, more on the application modernization perspective, where you know whether they're they are having those conversations about, you know, structures in business and technology that are set up and how we move through those to be effective and software delivery, or, you know, more just in the pure software side of the house. Hey, we've got older things, we want to bring them forward. Right, it's come to modern IGHTS. What do we do there? So it's IT'S A it's a big spectrum that we're comfortable working GOSHA. Do you find that in the your enterprise customers that you're seeing a much harder shift towards okay, I have software, I I have technology in general, right, just to be abstract, and that is now a core component of how I do business, even though they may move freight or...

...they may be, you know, manufacturing goods. Do you see do you see that change where they view technology as a core component even though they're not a technology company today? I think it depends on the industry and and sort of my take on it over the years has been if you're working in finance, if you're working in insurance, that shift happened a long time ago and most of the most of the bank or most of the insurance company is aware that software is how we do business. The if your industry was using more sort of software as support, those industries are little bit slower to come to it right and and in particular, so I'm located in the Midwest. You know, there's core industries throughout the midwest that might use software in the day to day of producing their products, but don't necessarily think about software first. Right, like if you're if you're manufacturing hard goods for construction, you might be using an awful lot of software, but it may not necessarily have become, you know, a primary concern of the company to start to think about the software development happening and inside of it as like Hey, this is foundational. We can't change you know, we can't. We can no longer think of the to a separate we can no longer think of it as a grissenter for what we're doing. Right. Yeah, yeah, it's interesting with you know, those voticals. You know, cross all of them. You know, healthcare has made huge jobs. Finances obviously made huge jobs. You know, they go softwarees is important as the care we provide or the transactions that we process on behalf of our customers, because it's all being done through software at this point. Yeah, whether for speed or efficiency or just you know, general getting it you know, getting things done. So yeah, you know, you look at some of these maybe more traditional industries, you know, I've seen I've seen a change and like the way they view technology. They go we have technology, it's it's old, we need to modernize. But that gap between my main frame where I used to enter in all my data and where I need to be from a web two perspective for my customers are maybe in a web three point Oh, if you're tracking to that. Yeah, you know that that gap is really, really important for our success. You know. So like we're finding, you know, as we focus more on infrastructure in our business, that Shat us off. We're seeing the application trickle down into those considerations just there and it's a big part of you know, it's like infrastructure and just software development or starting to converge in a way that we've probably never really seen historically, at least in the last twenty years. Yeah, I expect it's actually probably very difficult for if you're in an enterprise at organization and and you've been working in in a mental model of infrastructure being independent from the applications, that it's it's converging. You know, maybe not as quickly as I would love it too, but still like it's converging pretty quickly. If you're if your mindset is still very much like the infrastructure is independent from from the code. Right, like right, you start to see what, Hey, you know, where does the line for application developers begin and end in terms of supporting this thing? You know what, when you think about like what App Times like or when you think about what disaster recovery might look like. You know, those sorts of things. I think the previous paradigm was to have sort of a build run paradigm around that and like the concerns became the concerns of the run team. But more and more folks are shifting to building teams that you build it, you own it, right, and those things become in separable. And so those the paradigms of having a knock or the paradigms of having, you know, the run team take care of, you know, certain things and other things get funneled back to the the build team in a backlog is going away over time.

And the software, or at least you know, the you know, I would still think of it a software, even if the infrastructure team is still thinking about how to manage it right, like when you're thinking about Coubernetti's kind of large scale you you know, the devops paradigm in a lot of places kind of got set down as like okay, cool, well, devops would probably still be like the run crew or still be the infrastructure folks, so let's go figure out how to distribute it over there. And it's just blending in ways that make it hard to sustain that separation or those silos. Yeah, well, let me let me ask you this. So living through the whole proliferation of the concept of devops, and I use that term carefully, what large air quotes are? And Yeah, absolutely. You know, I've kind of come to the side where, you know, we we took a concept that makes sense right, where we have two distinct groups within an it organization and they historically don't work well together because they're usually compensated differently. They have different goals, you know, one is to build an extent, one is to keep the lights on and have up time. They're always in conflict. So what I saw kind of early on was organizations would create a deveops team, like their own little team, and they'd go your job is to you know, devop stuff, you know, just being absolutely as crude as possible, and then that team ends up being kind of ostracized from both groups. Have you seen a similar and you know your time in the space, if you seem kind of a similar concept where we create like almost like a tiger team? You know, these folks do develops and they're here to help you, but the traditional operations and then the software development shop still struggle. It's yeah, it's it's pretty I would say that's pretty consistent with my experience. Like, in particular, if you wound the clock back, you know, seven, eight years ago, I think that that Tiger team was like most definitely the thing that was happening Dev ops was, you know, like a conversation. The the folks who were more comfortable kind of like playing, you know, playing across the spectrum and weren't to worry about it said, oh, yeah, like that. That seems really compelling to me. I'd like to pick up, you know, a set of skills that kind of live in different areas, and I like the operation stuff. I like thinking about how to you know, availability, how to make things scale, how to do stuff right. I like gabbling with code. This all sounds really cool to me. And then you had folks that were like now, some of that sus are really didn't occur to me. I like to continue to kind of stay, you know, much closer to the technology that I'm kind of trained on and where I'm comfortable. And so, yeah, the tiger team started to form by, you know, from the hand raisers and the curious and the folks who wanted to kind of stick with comfort, kind of stay in their own camp, and so naturally there was there was a split there. And then the folks who were kind of hand raising it to go work with the APP development crews never got far enough up stream with them to sort of like work, you know, seamlessly. And there's complexity there. That's that's not tom blame one side or the other, I guess, but like right, getting very naturally there's that separation that you're you observed as well. Yeah, and you know, I think you know from what I've seen, the biggest change has been, like Cubernetti's is is kind of put a lot of pressure on that relative dysfunction, because if you don't have some type of unification between application owners and infrastructure people, it doesn't work. And you know now that everyone's, you know, running to implement Kubernetti's everywhere. Was it's the the platform of the future. You know, it's got its own, you know, set of unique qualities and challenges, just like anything does. That's right. We're seeing that we're doing the same thing we were doing ten years ago. We're going hey, the people who, you know, own and operate the platform actually have to be in sync with the people who build applications, because if you don't do that, you're literally just going to...

...knock everything over all the time. Yeah, they if you silo those two things, then one of the immediate pain points become the communication barrier between those two silas, right and right. And so the more fluid it is, like the most when it's at its most effective, like you're watching high frequency communication between infrastructure and application development. There they're working kind of hand in hand. Or we do a lot of like I mentioned before, we do a lot of extreme programming techniques. So we do a lot of pairing right, and you know, some my some of my favorite signals there that things are going well is, Oh hey, the you know, the the APP developers and the infrastructure folks. They have part in time of the color. They're going to sit down and they're going to work on stuff together to kind of help meet each other's needs of the it. So I I know but by the fact that the pairing with each other, that they're working on speaking the same language and we're not, we're not throwing things over the wall, and that that helps told me that we're not going to have future. Well, it helps reduce the amount of future pain as kind of the signal that I get out of that. Sure, okay. Could you for the for the listening audience s double click into, you know, extreme programming, like just that concept, you know, for someone who maybe hasn't heard of that before. Oh Yeah, sure, happy to do that. So there was a crew, many years ago now, and and I want to say the early s if I remember right, working on working on some software together and they were, as the story goes, the the software build was kind of as difficult as it could get, and so they started to talk as a group about, you know, what could we do to to favor the things in programming that we think are better right how how can we start to take the practices that we know help make us productive and really emphasize those? Because if we're, you know, if we're having a hard time right now and we think we're kind of at our lowest point, we don't think that emphasizing these would get us any lower. So let's the'll start to work on it. Kent back was the, I think, the person out of the group that probably did the most sort of formal publishing on it. So if you want to go read more. You can backs books or the best remain the best sort of introductions and like how do I start to think about it from a just pure text perspective? But the the general ideas, like let's take the things that we value and we know are good and like, what would it look like if we dialed them to the extreme right. So, you know, if we think that code review is going to be you know, it is one of those things that help us work better as a team. What would it look like if we did that to the extreme? Well, that might look like real time code reviews. So instead of paring you, instead of working individually, where I work on code and then you know, then I say hey, make here's my code through a poor quest can you go read it right you and I just work on code together, because then, instead of having to wait that time for feedback right or and you know, and the dynamics of I've handed something to you, can you take time out of what you're doing to work on it? We just work on it together. We're going to grow from each other. Our thoughts are going to go into the code the first time. We won't be doing handoffs over the wall. Will have these very short feedback cycles with each other and we're both going to improve through it. And so, you know, it's looking at at the practice levels, looking at aspects like that, that that say, like what gives us good, you know, what gives us good feedback loops? What helps us push stuff where out? It's a lot of the extreme programming values are well, a lot of the extreme programming crew from from back in the day, where the same people that were writing that the original Angel Manifesto, and so you see kind of a lot of overlap between, you know, the the Agile Manifesto and what that crew believed to be helpful in software. And then you know how that sort of hits tools and practices, you know, on the front lines of doing and so it's a lot of as I mentioned, it's a lot of the agile values, but it's also, you know, from a practice perspective, like full time, well, not necessarily full time pairing, but like knowing that, like hey, when we work together, it's sort of changes the dynamic of how we do poor quests. It gives us an ability to like talk more seamlessly, give it's ability... learn. So let's favor that one. We can test driven development right, really tight feedback loop around I'm going to write a test. It's going to explain what I think we're going to do. It gives us an opportunity, if we're pairing, gives us an opportunity to talk about what we think the software is going to do before we actually go implement software. So we have this nice tight feedback loop again, like if we're paring, through the pairing, but also through with with the computer in what we're doing right, like hey, I think the software should behave this way. It didn't write. Naturally, we're writing the test first. Now we write the software and and we would expect it to pass and the computers giving us immediate feedback on, you know, or our programme environment is giving us a feedback on yeah, that did exactly what it did. You know, you thought or didn't think it would do. How do you want to change it? And then, you know, going down the kind of path they're like continuous integration. Was that with? You know, was a big piece of the puzzle as well because, again, in the theme of feedback loops, right, we want to do, we're writing these tests. Were working in our local world. You and I are APP development team might be much bigger than you and I. We might have, you know, four or five pairs of developers going. If we're doing the pairing thing, how do we want to keep all of us and saying how can we have again, a nice tight feedback loop across all of us? You know, what do we do to start to make sure that the software is working? Can we when we integrate our code together, can we run those tests all the time and give us feedback very quickly if the test pass or didn't pass? Can we try to make a build and getting back very quickly if the software delter failed to build, and then we can sort of adjust our ourselves, you know, accordingly. Right. So, the the those are kind of extreme programming, you know, on the front lines or in the trenches, if you want. Got No thanks for explaining that. The have you seen that significant change in some of those practices in this world you know living in? Or guess we're still living in the pandemic. So yeah, and any significant changes you've seen? Tweaking were like, you know, pair programming, like you're sitting next to each other and a lot of you know, in the old way. Now everybody's remote. I would imagine that looks or feels a little different because doing that over zoom maybe tedious. I just actually don't know. I'm just curious. There's certainly more overhead to it, right, like sit together. There's a huge advantage to sitting in the same space. When when you and I, if we're sitting at the same desk paring together and our product manager is right across the desk. Again that theme of like short feedback loops, it's really easy to be like, Hey, we have a question about this. Can we chat about it? And we all three get together and we're looking at the same stuff and we're working out real time. Right, if we're developing a web application, we got a question about something in the interface, right, or how behavior should happen, and we can just pull our, you know, our product manager or designer over and how that conversation or a subject matter expert and how that conversation. That the overhead of that's really minimal. In a remote world there is additional overhead to it, you know, and it's it is not. It's non trivial overhead, I would say, but I don't think you know the game of optimizing your communication just because you're doing it remotely doesn't mean they should, you know, be doing it right, like most software. But I still personally believe the hardest parts and software or making sure we're communicating about the right things. And so, you know, while while sit together gives us a bunch of short cuts in that our guard, it doesn't necessarily change that. It's still the hardest part of software my opinion. Right. So how we have those conversations and what we talk about we solve the work for. But yeah, I think the first time I watch somebody remote pair was probably two thousand and ten and I was doing some remote pairing as early as two thousand and twelve, and so it hasn't changed substantially since two thousand and twelve. I think we've kind of learned over the years. It's hard if, if you've got part of the team remote, you need treat all the team is remote. Right. So even if some folks are sitting together, it's better to work in paradigms where, you know, one remote, all remote is favorable for communication flows and then you...

...know, pandemic wise, right, like we continue to be as much as we want to get back together, we still largely continue to be all remote in the way that we're working and I think that's really cool because we can we've got access to talent that we wouldn't, you know, if we just said, well, how you need to live next to one of our office spaces. That really changes the talent pool and and the ideas that are available to our teams as we're building software, and so I think there's, you know, the distributed thing. While there is extra overhead there and people have to be mindful about that, I think the a distributed things really abused because they let you start to bring other folks in your team that wouldn't otherwise be accessible. That's good point. The world's become a lot smaller. It's that we hadn't done. All have to go into the same office or be in the same region. I mean we we're very regional focus business, so you know, but the idea of hiring people outside of hqu seemed daunting because we live in a large market. Not Anymore. Yeah, now we're like, you know, are you near an airport? Maybe we'll see, you know, just for the future, you know, if we ever get back to working somewhat normal. So you know, the the conditions have changed around that application. Modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and COUBERNETTI'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 click 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 (30)