Improving Software Development & Overcoming Modernization Challenges w/ Michael McCormick

ABOUT THIS EPISODE

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 scalingapplications and accelerating time to market to avoiding expensive license and costs, we discusshow you can innovate with new technology and forward thinking processes and save some cashin 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 MikeMcCormick of artum. He's the VP of technology. They help customers design newnew 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 softwaredevelopment and great customer story. So, you know, enjoy this. Thanksto red hat for continuing to support the application modernization podcast and hope you reallyenjoy this. Hey, Mike, Thanks for joining us today. Excited totalk to you. Yes, thank you for having me on. I'm excitedto chat good deal. So tell me, you know, just for our audience, you know, for the podcast we like to talk about stories aroundcustomers and their journey to application modernization. How you know you're off rains foryour organization may help them get there. Why don't you give us a littlebackground on your organization? Oh sure, yeah, so I work for acompany called artium and we've got a big focus on kind of the mastery orthe craft of software development and we work with customers in a professional service capacityin a couple different ways, and we build some internal software right it aswell. And so the largest probably portion of our business by people part ofan application new development group that we call technology labs, and so it's professionalservices, you know, helping folks build software. We work kind of anywherein 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 fundingrange right where they're working to either find product market fit or they're starting thescaling process because they have the type by the tail as or. And wework 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 needto figure out what to do next, right like we want to bring itforward and make it more useful. So our technology labs, teams work usinga 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, froma product management and design perspective, we typically kind of follow things like, you know, lean startup style product management perspective, right, like leanpridization, the backlog or you might call a dual track agile. From productdesign, we do a lot of user center design as we approach what we'reup to. And so, you know, most of our engagements from technology labslook like some combination of engineers, product managers, designers working with ourcustomers to build software collaboratively, you know, often in the trenches with customers workingalongside of us. And then we also have what we call talent labs. So talent labs it is US looking at. You know, how wehave hired technologists over the years to do the kind of work that we wantto do and and focus on craft, and a lot of our customers haveasked that over time as well. And so our technology labs team is bothwho we use to help do our sorry, our talent labs team is. Sowe 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 softwarearound the software development life cycle and how people collaborate in and so that's notlaunched publicly yet, but we're working on it inter got. Okay, soyou'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 talentlabs piece because we actually do something similar here. So it would be interestingto talk through that. What is is there a unique qualifier for your customerswhen they come to you, like, like what types of customers fund didyou get? Are you guys strong in a specific industry or is it reallyjust for solving for what they're trying to do from Software Development Perspective? Anytrends there? Yeah, it's definitely solving what they're trying to do from asoftware development perspective, right, and so it kind of depends on where thatorganization is and there their maturity of the perspective right. Like my mental modelfor it is sort of you have start ups who might be thinking as softwareas foundational for what they're doing. It's core of the business and how wedo it right. Maybe software is not the only thing they release in theirproduct, but it's absolutely a piece of the product. It's inseparable from theproduct itself. Those folks, when they come to us, we're usually workingwith them in capacities of Hey, it's where we're either trying to realize ourapplication. You know it's it's it's in our heads. It's in we knowthe markets there. We want to we know how to do it. HelpUS use tools to to start to realize it and software and bring it forwardand Testin. So folks that were working with in that sort of like youknow, seed or a round of funding. We're definitely doing that kind of zeroto one motion with them. And those folks there, they know weshow up with technologists, so they're showing up with like clarity on what itis they're after. What is that market? How do we achieve at things likethat, and we help kind of take those those their understanding of whatthey're trying to build and realize it. The folks that are sort of inthe B Toc funding range like usually with those companies, what we're doing iswe're helping them scale their their products their processes as well. Right. Sowhen 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'regoing into a phase where it's really easy to go from being able to movefast all the time too there's there's so much happening around as so many newpeople, things like that, that we are ability to really software starting toslow down. So a lot of our customers in that range of kind ofnotice that they want to make improvements there, you know, either in the waythat the people are transacting around software or and or how they build it, you know, more from a technical perspective as well. And then fora lot of our enterprise customers, and many of our enterprise customers are lookingat 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 theproduct 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 theidea 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 itmore, 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 callmore like transformation, where we're trying to think more software first. Youknow how much that that work? What's the relationship between business and technology tokind of make that happen? How do we break down structures of we currentlyhave that aren't really helping that? Or they maybe, you know, moreon the application modernization perspective, where you know whether they're they are having thoseconversations about, you know, structures in business and technology that are set upand 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'SA it's a big spectrum that we're comfortable working GOSHA. Do you find thatin 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 tobe 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 technologyas a core component even though they're not a technology company today? I thinkit depends on the industry and and sort of my take on it over theyears has been if you're working in finance, if you're working in insurance, thatshift happened a long time ago and most of the most of the bankor 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, thoseindustries 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 themidwest 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'remanufacturing 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 ofthe company to start to think about the software development happening and inside ofit as like Hey, this is foundational. We can't change you know, wecan't. We can no longer think of the to a separate we canno 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. Financesobviously made huge jobs. You know, they go softwarees is important as thecare 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, whetherfor speed or efficiency or just you know, general getting it you know, gettingthings done. So yeah, you know, you look at some ofthese maybe more traditional industries, you know, I've seen I've seen a change andlike the way they view technology. They go we have technology, it'sit's old, we need to modernize. But that gap between my main framewhere I used to enter in all my data and where I need to befrom a web two perspective for my customers are maybe in a web three pointOh, if you're tracking to that. Yeah, you know that that gapis 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 justthere and it's a big part of you know, it's like infrastructure and justsoftware development or starting to converge in a way that we've probably never really seenhistorically, at least in the last twenty years. Yeah, I expect it'sactually probably very difficult for if you're in an enterprise at organization and and you'vebeen 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 wouldlove it too, but still like it's converging pretty quickly. If you're ifyour mindset is still very much like the infrastructure is independent from from the code. Right, like right, you start to see what, Hey, youknow, where does the line for application developers begin and end in terms ofsupporting this thing? You know what, when you think about like what AppTimes like or when you think about what disaster recovery might look like. Youknow, those sorts of things. I think the previous paradigm was to havesort of a build run paradigm around that and like the concerns became the concernsof the run team. But more and more folks are shifting to building teamsthat you build it, you own it, right, and those things become inseparable. And so those the paradigms of having a knock or the paradigmsof having, you know, the run team take care of, you know, certain things and other things get funneled back to the the build team ina backlog is going away over time.

And the software, or at leastyou 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 likeokay, cool, well, devops would probably still be like the run crewor still be the infrastructure folks, so let's go figure out how to distributeit over there. And it's just blending in ways that make it hard tosustain that separation or those silos. Yeah, well, let me let me askyou this. So living through the whole proliferation of the concept of devops, and I use that term carefully, what large air quotes are? AndYeah, absolutely. You know, I've kind of come to the side where, you know, we we took a concept that makes sense right, wherewe have two distinct groups within an it organization and they historically don't work welltogether 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 andhave up time. They're always in conflict. So what I saw kind of earlyon was organizations would create a deveops team, like their own little team, and they'd go your job is to you know, devop stuff, youknow, just being absolutely as crude as possible, and then that team endsup being kind of ostracized from both groups. Have you seen a similar and youknow your time in the space, if you seem kind of a similarconcept where we create like almost like a tiger team? You know, thesefolks do develops and they're here to help you, but the traditional operations andthen the software development shop still struggle. It's yeah, it's it's pretty Iwould say that's pretty consistent with my experience. Like, in particular, if youwound the clock back, you know, seven, eight years ago, Ithink that that Tiger team was like most definitely the thing that was happeningDev ops was, you know, like a conversation. The the folks whowere more comfortable kind of like playing, you know, playing across the spectrumand 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 Ilike the operation stuff. I like thinking about how to you know, availability, how to make things scale, how to do stuff right. I likegabbling with code. This all sounds really cool to me. And then youhad folks that were like now, some of that sus are really didn't occurto 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, youknow, from the hand raisers and the curious and the folks who wanted tokind of stick with comfort, kind of stay in their own camp, andso naturally there was there was a split there. And then the folks whowere kind of hand raising it to go work with the APP development crews nevergot 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 sideor the other, I guess, but like right, getting very naturally there'sthat separation that you're you observed as well. Yeah, and you know, Ithink you know from what I've seen, the biggest change has been, likeCubernetti'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 infrastructurepeople, 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 qualitiesand challenges, just like anything does. That's right. We're seeing that we'redoing the same thing we were doing ten years ago. We're going hey, the people who, you know, own and operate the platform actually haveto be in sync with the people who build applications, because if you don'tdo 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 immediatepain 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 itsmost 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 likeI mentioned before, we do a lot of extreme programming techniques. Sowe do a lot of pairing right, and you know, some my someof my favorite signals there that things are going well is, Oh hey,the you know, the the APP developers and the infrastructure folks. They havepart in time of the color. They're going to sit down and they're goingto work on stuff together to kind of help meet each other's needs of theit. So I I know but by the fact that the pairing with eachother, that they're working on speaking the same language and we're not, we'renot throwing things over the wall, and that that helps told me that we'renot going to have future. Well, it helps reduce the amount of futurepain 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, forsomeone who maybe hasn't heard of that before. Oh Yeah, sure, happy todo that. So there was a crew, many years ago now,and and I want to say the early s if I remember right, workingon 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, andso they started to talk as a group about, you know, what couldwe do to to favor the things in programming that we think are better righthow how can we start to take the practices that we know help make usproductive and really emphasize those? Because if we're, you know, if we'rehaving a hard time right now and we think we're kind of at our lowestpoint, we don't think that emphasizing these would get us any lower. Solet'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 formalpublishing on it. So if you want to go read more. You canbacks books or the best remain the best sort of introductions and like how doI start to think about it from a just pure text perspective? But thethe general ideas, like let's take the things that we value and we knoware good and like, what would it look like if we dialed them tothe extreme right. So, you know, if we think that code review isgoing to be you know, it is one of those things that helpus work better as a team. What would it look like if we didthat to the extreme? Well, that might look like real time code reviews. So instead of paring you, instead of working individually, where I workon code and then you know, then I say hey, make here's mycode through a poor quest can you go read it right you and I justwork on code together, because then, instead of having to wait that timefor feedback right or and you know, and the dynamics of I've handed somethingto you, can you take time out of what you're doing to work onit? 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 cycleswith 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 aspectslike 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 ofthe extreme programming crew from from back in the day, where the same peoplethat were writing that the original Angel Manifesto, and so you see kind of alot of overlap between, you know, the the Agile Manifesto and what thatcrew believed to be helpful in software. And then you know how that sortof hits tools and practices, you know, on the front lines ofdoing and so it's a lot of as I mentioned, it's a lot ofthe agile values, but it's also, you know, from a practice perspective, like full time, well, not necessarily full time pairing, but likeknowing that, like hey, when we work together, it's sort of changesthe dynamic of how we do poor quests. It gives us an ability to liketalk more seamlessly, give it's ability...

...to learn. So let's favor thatone. We can test driven development right, really tight feedback loop around I'm goingto write a test. It's going to explain what I think we're goingto do. It gives us an opportunity, if we're pairing, gives us anopportunity to talk about what we think the software is going to do beforewe 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 withthe computer in what we're doing right, like hey, I think the softwareshould 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 passand the computers giving us immediate feedback on, you know, or our programme environmentis giving us a feedback on yeah, that did exactly what it did.You know, you thought or didn't think it would do. How doyou want to change it? And then, you know, going down the kindof path they're like continuous integration. Was that with? You know,was a big piece of the puzzle as well because, again, in thetheme of feedback loops, right, we want to do, we're writing thesetests. Were working in our local world. You and I are APP development teammight be much bigger than you and I. We might have, youknow, four or five pairs of developers going. If we're doing the pairingthing, how do we want to keep all of us and saying how canwe have again, a nice tight feedback loop across all of us? Youknow, what do we do to start to make sure that the software isworking? Can we when we integrate our code together, can we run thosetests all the time and give us feedback very quickly if the test pass ordidn't pass? Can we try to make a build and getting back very quicklyif the software delter failed to build, and then we can sort of adjustour ourselves, you know, accordingly. Right. So, the the thoseare kind of extreme programming, you know, on the front lines or in thetrenches, if you want. Got No thanks for explaining that. Thehave you seen that significant change in some of those practices in this world youknow 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 youknow, in the old way. Now everybody's remote. I would imagine thatlooks or feels a little different because doing that over zoom maybe tedious. Ijust 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 thesame space. When when you and I, if we're sitting at the same deskparing together and our product manager is right across the desk. Again thattheme of like short feedback loops, it's really easy to be like, Hey, we have a question about this. Can we chat about it? Andwe all three get together and we're looking at the same stuff and we're workingout real time. Right, if we're developing a web application, we gota question about something in the interface, right, or how behavior should happen, and we can just pull our, you know, our product manager ordesigner 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 additionaloverhead to it, you know, and it's it is not. It'snon trivial overhead, I would say, but I don't think you know thegame 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 stillpersonally believe the hardest parts and software or making sure we're communicating about theright things. And so, you know, while while sit together gives us abunch 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 howwe 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 probablytwo thousand and ten and I was doing some remote pairing as early as twothousand 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 isremote. Right. So even if some folks are sitting together, it'sbetter to work in paradigms where, you know, one remote, all remoteis 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 andI think that's really cool because we can we've got access to talent that wewouldn't, you know, if we just said, well, how you needto live next to one of our office spaces. That really changes the talentpool 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. Whilethere is extra overhead there and people have to be mindful about that, Ithink the a distributed things really abused because they let you start to bring otherfolks in your team that wouldn't otherwise be accessible. That's good point. Theworld's become a lot smaller. It's that we hadn't done. All have togo into the same office or be in the same region. I mean wewe're very regional focus business, so you know, but the idea of hiringpeople outside of hqu seemed daunting because we live in a large market. NotAnymore. Yeah, now we're like, you know, are you near anairport? 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 RedHat, the world's leading provider of enterprise open source solutions, including high performingLinux, 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 showon your favorite podcast player so you never miss an episode, and,if you use apple podcasts, do us a favor and leave a click ratingby tapping the stars. Join US on the next episode to learn more aboutmodernizing your infrastructure and applications for growth. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (16)