Modernizing with Respect: Acknowledging the Best Intentions Behind Legacy Code

Hello and welcome to another episode of stories of facilitating software design and architecture. Today we are joined by

and architecture. Today we are joined by Michael Plot and Bea Nigel. Nikl um as I hopefully I got that right. Um and we're

going to hear a story from Michael. I'm

hoping that he's going to tell a brilliant story and then we're going to ask some questions and make some comments and see what happens. As usual,

I'm joined by my co-conspirators Andrew Harlo and Kenny Bass Shrier.

Michael, the floor is all yours.

>> Yeah, thank you. Um, I want to talk about a story that maybe quite a few folks encounter when they're working on legacy modernizations. I mean, it's a

legacy modernizations. I mean, it's a rare case that we work in our industry on the green field. Everyone who works in a larger organization deals with

legacy systems that are 20 years old, 30 years old where some old tech may be in place, but also maybe old processes and

I very often hear about from younger folks or from folks who come in externally like from [snorts] external consultants and I'm an external consultant by myself have been for most

of my career.

Oh, this legacy system sucks. This is so bad and we need to get rid of this and so on. And my story is um a little bit

so on. And my story is um a little bit about empathy in this case. And it was a

couple of years ago when I was a leading architect for a big legacy system modernization. And there was this was a

modernization. And there was this was a very old system, quite a bit of a cobalt code base involved mainframe systems,

but also Java swing user interfaces and and a lot of that stuff. And a lot of that embedded in a very uh hierarchical organization. Yeah. With a lot of

organization. Yeah. With a lot of command and control, a lot of micromanagement. They claimed to be

micromanagement. They claimed to be agile because they used scrum but it wasn't like really agile in any way in that. But there was the decision to

that. But there was the decision to modernize this thing. And of course all the fancy buzzwords were thrown around.

microservices, cloud, agile, domain driven design, Angular, Spring Boot, whatever. Yeah.

All the all the stuff DevOps of course as well and Kubernetes of course all the all the fancy stuff what you usually

hear when you do CDD which I refer to as conferenced development. And so

conferenced development. And so it was hard to sort these things out.

Yeah. to really bring in some zens a part of the modernization frenzy.

But I realized there was one person who was resisting very very heavily in that way. And part of the resistance I could

way. And part of the resistance I could understand but there were other parts of the resistance where I really struggled

to get a grip. Yeah. To really get into that why is this person acting like that? and especially in um like higher

that? and especially in um like higher management circles when the management came together in Germany it's called the lancos steering committee is probably the best

English term for that the there was sometimes vetos about things where I was like why why is this person acting like that

and there were quite a few voices that said oh someone from the upper management should get him in control and

uh whatever. And I

uh whatever. And I I reached a point where I was so fed up with that person that I was like, "Okay, I have nothing to lose." I went up to him and said, "Hey, can I have 30

minutes of your time? Why? What do you want? What do you want?" And I was like

want? What do you want?" And I was like sort of a target for him because I was driving part of that modernization.

And I was like the marketing phase also for the modernization so to say. He was

like, "Ah, what do you want? what do you want? Why should I spend time with you?

want? Why should I spend time with you?

Blah blah blah and all that stuff. And

he he agreed to have a meeting with me.

And it was at the end of a business day, like 400 p.m. 5:00 p.m. something like

that. And I was like, "Hey, I don't understand parts of your system. There

is something that I don't see that you see, and I would like to understand that." um you're you have a history of

that." um you're you have a history of over 30 years in that company. You know

way more stuff than I do about this company, about this system and so on.

And I would like really to to really understand where your assistance is coming from because I want to avoid making any mistakes or not understanding

a certain context. Yeah. Not seeing a certain context. Yeah. Maybe I'm blind

certain context. Yeah. Maybe I'm blind because I'm an external consultant and I don't claim to know everything because I'm just an external consultant.

He brushed me off. He was like, "Go away. What is this crap all about? Well,

away. What is this crap all about? Well,

you want to throw everything under the bus and blah blah blah and and and so on."

on." And I was like very dissatisfied with that and left. And two weeks later, he

came up to me. He said, "Hey, let's meet again." I was like, "Oh, interesting."

again." I was like, "Oh, interesting."

And I came into his office and he said, "You need to thank my wife for this meeting." I was like, "Okay, I'm getting really curious now." He was

like, "Yeah, when you came to me, I was really pissed. I was really angry. And I

really pissed. I was really angry. And I

came home and took the anger to dinner."

And my wife was like, "Why don't you tell him what's what's this fuss all about? Tell him." And so he was like,

about? Tell him." And so he was like, "Yeah, okay. I'm going to tell you now

"Yeah, okay. I'm going to tell you now very honestly, and this stays in this room." I am allowed to talk about this

room." I am allowed to talk about this publicly, but in a very anonymous fashion. So I won't disclose the

fashion. So I won't disclose the industry, the area, or wherever. I'm

allowed to tell the story, but no further details. Yeah. So, um I'm not

further details. Yeah. So, um I'm not stabbing his back behind and right now.

And um he said, "Well, listen. I started at this company when I was 16 years old.

I'm going to retire in 5 years."

And I was what you young folks now now nowadays say the rockstar developer of

the company. I created all of this.

the company. I created all of this.

This is my baby.

And now everyone is running around claiming that this system is a pile of crap and that it needs to go away.

And I am struggling with that. are you

actually aware how much money this system earned the company?

And I was like, okay, thank you very much. Now we're talking.

much. Now we're talking.

I understand your context.

I understand why you think that way. And

by the way, what I always say is to any external consultant or to any facilitator when you deal with legacy, that system must have been very very successful in

the past otherwise they couldn't pay your daily rates right now. and always

treat legacy with respect and always assume that no one 20 years ago got up saying, "Oh, let's build a really bad

system." No one ever did that. I'm very

system." No one ever did that. I'm very

sure. And um so so I I was talking with this person and we talked a little bit about context. The context back in the

about context. The context back in the day was what Gregor Hope very often says, economies of scale for systems.

Yeah. So reusabilities, centralization,

Yeah. So reusabilities, centralization, control, but the context has changed and I'm also quoting Gregor towards

economies of speed. Yeah. And I said, well, you made a lot of really good decisions in the context that you were in, but the environment maybe changes.

He was like, I never looked at that from this perspective.

And I said, okay, I'm not going to give you any advices right now. Let's leave

this where it is. I'll think about it and I I'll come back to you. A week

later, I approached him and asked, "Hey, do you have more time? I have an idea."

And I said, "Hey, actually, you have a really cool chance in your career at this moment.

You can be you are already the architect and the the developer the lead developer for the very first very successful systems architecture and

system for that company that earned them millions if not billions.

But you can now open the gate for a context switch of this system.

Yeah. getting that system ready for a changing context that's happening now.

And you can bring in all your knowledge about these things, about the company, about the system to be the path maker for the second very successful

architecture in there. And he was like, "Michael, I want to kick you out of the room right now because I hate your your positive attitude all the time, but I'll

let it sink in." And a few days later, I just received the mail I'm in. And that

opened many doors. And what I want to tell with this story is don't brush off resistance

and always try to find out where this stems from. Yeah, I would say 98% of the

stems from. Yeah, I would say 98% of the people don't work on ill intents or bad

intents. They don't have bad intentions

intents. They don't have bad intentions but they have a certain perspective and when you facilitate things when you don't try and I think that's a key

differentiator between architecture as a hierarchical position of power where you say hey I'm the big boss architect now and you do it my way and shut up and the

discussion is over versus facilitating architecture. I think what what is very

architecture. I think what what is very important when you are a facilitator and when you want to facilitate architecture especially yeah also when you want to

facilitate architectural change you need to have empathy you need to try to understand these dimensions you need

to understand where resistance from certain players and key players stakeholders comes from and then you can actively work with that I

that can open many doors. And this

question hey why are you like that? Opened quite a few doors. Hey, could have also gone

few doors. Hey, could have also gone terribly wrong. Yeah, that they kicked

terribly wrong. Yeah, that they kicked me out uh and so on. But sometimes you you have to take a risk and that's risk-taking. Yeah, these things can go

risk-taking. Yeah, these things can go wrong, but there is no guarantee for that. And also part of that empathy is

that. And also part of that empathy is try to understand the context. And no

one got up and said let's build a horrible system where they will hate us 20 years later. And no one ever did that. No one probably

that. No one probably thought about that system existing 20 years later when they designed it. So

that be my story that I want to tell.

>> Thanks. So you the at the end especially I'm I'm very curious because at the end you say I take a lot of risk and I think a lot of people myself as well in the past taking that that does a lot to a

person when he kicked you out sort of like kicked you out or say it's nonsense right there was two weeks in between how did you feel in those two weeks did you ever meet him then and how did you cope

with that I'm very curious because many people probably find it hard to do this because they feel very uncomfortable getting into

that situation. At least I am still to

that situation. At least I am still to this day feel very uncomfortable with that. Were you?

that. Were you?

I think I have quite a bit of a resilience with these things. So, um I don't know why. I can't tell you. I

didn't train that or whatever.

I can live very well with people not liking me. Yeah. So that gives me that

liking me. Yeah. So that gives me that doesn't mean that I don't care at all.

Yeah. Uh but I can uh I can draw very good boundaries for myself. I don't know why how that came to place. I never

explored that. I'm not a psychology person or anything like that. But it is like that. Of course I encountered him

like that. Of course I encountered him in meeting and I just ignored the situation.

I I just dealt with it like this never happened. I remained professional. I

happened. I remained professional. I

didn't take it any in any personal thing. I always say you can toss a lot

thing. I always say you can toss a lot to my head in a business context and I can still go out to a bar with you.

Yeah. Um so so that doesn't mean that I appreciate any toxic behavior or there are certain boundaries to that. Yeah. Um

but I for myself I can draw very good boundaries I think so that it doesn't bother me too much but I thought about that taking that risk very very

explicitly so I was prepared for various situations how that could go along.

Yeah. So when I do that that stuff I just don't do that intentionally. Oh

let's go in there and whatever. So, I

weigh in the pros and cons and I already have a plan how I deal with that if things like that happen.

>> But I think what you just said, the splitting of the person and the conflict or the topic, something that I feel like makes it very essential to feel respected even though you might disagree

on something. Um, and that already helps

on something. Um, and that already helps people to actually be digest what you just said and about this what you said Kenny like what helped me in this is to

accept that some people need time and especially when it's about switching perspective and being like saying okay I was wrong or this takes a lot of time to

jump over your own like shadow to to be like okay I should maybe I need to I need to switch and this takes time and being patient and to learn to be patient And to tell one yourself every once

again be like hey >> give the people time you won't get anywhere if you stress them let them come back to you instead of forcing it too much that helps me in such situations at least

>> and I think you said something very interesting so I I do uh so everyone's different right so I do have personal problem with people not liking me but what you said was very interesting I

think we should take the same approach which I always tried to ask to people as well and I think that's a learning point is before you go into that discussion or

that conversation try to already imagine and it's a stoic thing actually found out later on stoics do it a lot that stoics are not emotionless they already

went through the emotion before it happened so that in the moment they are more grounded so I think that's an interesting thing that I do as well like

I imagine what will happen during that and I weigh the pros and cons and then I already went through what was going on.

Not always, right? Yeah.

>> I find it really I find it really interesting that you're able to set really good boundaries while at the same time you're able to be highly empathetic. Uh I think that is a very

empathetic. Uh I think that is a very very hard skill cuz I find for example I can have high empathy but if it's someone that is attacking me personally

I find it very hard to like it's something that cost me emotionally. It's

a it's emotional work I have to do. Do

you find that you have to do work or is it you are doing the boundary stuff and it doesn't require any emotional work for you? I don't take these offenses

for you? I don't take these offenses personally to be honest because I think you can for instance exchange me for

Andrew for you Andrea for Kenny and the result would be the same. It's not uh it's not I I don't think that I personally get attacked. I think the

position that I am in is the one that is being charged. Yeah. So, uh, I don't I I

being charged. Yeah. So, uh, I don't I I don't think that this person thinks I, Michael, am a

full-blown idiot. I think this person

full-blown idiot. I think this person has a problem with the task that I have, with the position that I'm in. And I

think that is the first boundary that I draw.

>> Yeah. I wanted to there's so I think there's one thing you said Michael I thought was super interesting because people talk about like certain types of people take risks and they always mean like intellectual risks

or like financial risks or some other kind of risk but you took like an emotional risk with yourself just to like like I would be like Andrea I get very physical reactions to these things

and whether I can like think about you know intellectually I could be like they're talk like everything you said I'll still feel it really physically physically in meetings which is not fun.

Um but then the person as well then you gave them space and they took an emotional risk and I think that especially in software where we get super emotionally involved in what we build and the results of those things

which is exactly what you described right I think that kind of risk is a really big key part of this and it's less it's less talked about I think people are like oh yeah we just we ran

fast and broke things and you didn't you like went slow and like listened to people and that had the biggest impact right the more you push this person, it probably would have got worse, worse, and worse, right? Then his wife would have been, "Yeah, you're right. This

Michael guy is a complete jerk. You

should really make his life hell."

>> But instead, it was different. So

>> yeah, I completely agree, Andrew. It's a

construct, but because we do get emotional because angryness is also an emotion that people don't construct as an emotion, but there's always underneath that. So I think that's

underneath that. So I think that's something we should talk about more often.

>> Yeah. And I mean something that also I tell my teams that I work with when we have discussions that it's not about my idea or your idea but it's about ideas that one person brought up or another

person brought up. But if you get attached to the idea or to your idea or for example in Michael's story to your change if Michael would have said hey this is I want to drive this change because this is my initiative then you

get emotionally attached and then it's harder to detach this from you as a person and that also helps a lot. I mean

sometimes it's hard it's easier to say and to consult other people to make hey don't take it as your decision or your idea still it helps to repeat it for one

other people but also for yourself. I I

have a question uh and this is a very practical consulting question that I think most of us will be able to relate to which is sometimes I see the same thing that that that you see right and

and on the thing of this person why are they acting like this I I do believe people are self-consistent my question is how do you manage to

carve out time because even this half an hour investment and this other hour investment like as consultants we tend to need to uh have to explain all of our

time. Um and sometimes I can't invest in

time. Um and sometimes I can't invest in all the wise I want to answer. Um and

and this is this is a a a hard problem for the consultants and also for the companies. So I think both are

companies. So I think both are disserviceed by our lack of discretion on the usage our time. Sometimes I just do it anyway because I think it's a risk to the project like a high risk but it

also means that we're losing on some uh good key learnings. I wonder how you manage that or if you kind of built in

some some you know discretionary use of meetings or whatever.

>> Um I must say that I've rarely been in an environment where

I had to justify 30 minutes of my time on a time sheet.

Maybe I was just lucky. But that 30 minutes or something or scheduling a meeting with some key stakeholder has never been seen as something that I

have to justify. And if someone would have come to me and asked, hey, why did you what were these 30 minutes on your time sheet for or this one hour on your

time sheet for? I would say hey listen I'm one of the driving architects for this change and I think stakeholder

management and dealing with stakeholders and talking to stakeholders is one of my key tasks of an architect. Yeah. Um I I

would say it's not my task to what I let's say set up some really low-level details in the Kubernetes installation. Yeah,

maybe. Yeah, I think it's my task to bring to align the perspectives of various stakeholders together. Yeah. To

create a shared understanding about this modernization and this is one of the key stakeholders. So I think it's an

stakeholders. So I think it's an integral part of my job to talk to this person and if you have a different

perspective on the work of an architect.

Yeah. Uh we have to talk about my role in general. So that would be the thing

in general. So that would be the thing that I would say if someone would have challenged that.

>> It's great to hear. It's great to hear that because it's like sometimes I hear discussions about oh you know architects shouldn't really need to talk to stakeholders in a one-toone level. I

find it mind-blowing but it's good to see that I'm not alone.

What what I always say I sometimes teach software architecture foundation courses for the ISAQB and what I say in these trainings to

aspiring young architects is that stakeholder communication in a way that is suitable for certain stakeholder groups is one of

the most important key skills for any architects in my eyes. Yeah. So I think if you would ask me what is the key skill of a really good architect, I I love quoting Gregor Hopy. It's riding

Gregor's elevator. Yeah. Being able to talk to stakeholders on various levels with various perspectives in a way that they understand you. Yeah. Don't bring

out a live coding session to the sea level. Yeah. And don't bring Mckenzie

level. Yeah. And don't bring Mckenzie styled slide decks to the engineering team. Yeah. Uh to to to say it in a very

team. Yeah. Uh to to to say it in a very blunt fashion. And I think that's one of

blunt fashion. And I think that's one of the most important skills as an architect >> and and I want to add to that >> not not to an architect to architecture.

If you look at domain design the most important aspect of domain driven design is understand the problem. Who knows the problem? Stakeholders.

problem? Stakeholders.

>> Absolutely.

>> If you don't have the people on board, you cannot drive any change because the change is in the people and not in the system in the end.

This is this is uh it's been uh wonderful to have you in this uh episode. I love the I love the the

episode. I love the I love the the topics that we touched on. Uh thank you so much for for joining us, Michael and Bea. And uh we'll see you again in the

Bea. And uh we'll see you again in the next episode. Goodbye.

next episode. Goodbye.