When I think about well-crafted software is called that we are not scared to change the code clearly specifies. What it does. When we change one part of me. Don't break the other. You always feel that you are in control. You are controlling the codes, not the other way around. Hey everyone.
My name is Henry Surya be Robin. And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello. Hello. My friends. It's always great to be back here again with a new episode of
the tekhelet journal podcast. I'm your host, Henry Surya. We do one, as always. Thank you for spending your time with me today, listening to this episode. If you haven't subscribe to the podcast, please take a few seconds right now. To subscribe to the tekhelet journal. Podcast on your favorite podcast. Apps such as Spotify and apple podcast Google podcast and many others. We can also find and listen to tekhelet journal. On YouTube and make sure to check out different playlist
that I have on the channel. Also do check out technology. No social media channels on LinkedIn Twitter and Instagram where I post interesting quotes and just from each episode daily and drawing a growing and thriving Community there and help me by liking and sharing those insightful quotes with others such as your colleagues and friends who will also benefit from the contents from my amazing gas and for any of you Avid listeners who would like to support me and make
contribution to the show. Please consider joining as a patron by visiting technology, you know, dot? F / Patron, your kind support were tremendously. Help me towards achieving the goals that I'm currently running for the show. For today's episode.
I am happy to share my conversation with Sandro Mancuso. Sandro is the author of the software Craftsman book and the co-founder of code Durance in this episode Sandra. Ow, shared his great insights on how developers and Engineers can become a software Craftsman by
adopting. The professionalism pragmatism and pride mindset in order to achieve higher levels of technical Excellence. We started off our discussion with Sandro's career Journey, how he adopted the software craftsmanship mindset in his career and started the London software, craftsmanship Community. We then dive deep into discussing about software,
craftsmanship. It relates to Agile and the other software movements, and Sandra also shared his definition of a well-crafted software and the importance of why, we should always aspire to build a well-crafted software. We then move to discuss his latest work on software modernization. And some of the principles behind a successful modernization Journey including some of the valid business drivers and common impediments of a software modernization effort.
In the end Sandro. Again re-emphasize, the importance of pragmatism for us, technology practitioners and shared a few things on how we can improve our pragmatism in our career. Personally, as an engineer at heart, software craftsmanship is an important mindset. That I think every engineer needs to adopt when building software either at work or personal project. It is one of the most important and distinguishing attributes that separate great engineer. From the rest.
I also highly encourage you to read Saint Joe's book. The software Craftsman, which I find highly insightful, a fun to read with. Lots of practical tips that you can adopt straight away to improve your craft. I hope you will enjoy this episode. And if you like it, consider helping the show by leaving a rating review or comment on your podcast app or social media channel, those reviews and comments are one of the best
ways to get this. Has to reach more listeners and hopefully they can also benefit from the contents in this podcast. So let's get the episode started right after our sponsor message. Are you looking for a new cool swag. Technology, you know. Now offers you some swags that you can purchase online. These tracks are printed on demand based on your preference and will be delivered safely to you all over the world where
shipping is available. Check out all the cool strikes available by visiting technology, know that / shop, and don't forget to break yourself. Once you receive any of those tracks. Hey everyone, welcome back to another show of the techniques. You know. Today. I have a special guest with me. His name is Sandro Mancuso. He is a person who is well known about software craftsmanship. In fact, he wrote a book about it. The software craftsmanship. I think he was in 2015 if I'm
not wrong. So again, very pleased to meet Sandra today Sandra welcome to the show. Hi, Harry. Thanks for having me. It's a pleasure to meet you. So Sandra to start with, normally I would ask the courage, any of my guests. So can you share with us maybe some of the highlights of turning points in your career? So I started my career about trying t. Five years ago. I started in Brazil, I grew up in the middle of nowhere in Brazil and it was a very long journey from where I was born.
And where I grew up to where I am. Now, today. I live in London. I have my own company. So that was a very long journey. Ernie in there. I think that I can share the things that I've judged important from these Journey coming from a very remote place in a country. That is not very well known for technology to what I am actually. So, one was Drive. I really wanted to make sure that I would be good enough to work in good conference. So I always try to find good
companies. When I was able to find a very good company. I was also trying to find the right place in that company's. Well, it's also fine for everyone. Wants to be in a good company wants to be in the good teams. But one thing that I realized very soon is what do I bring to the table? It's fine for me to say like yes, everyone wants a good job. Everyone was to be part of a great team and stuff.
But what do you offer to that? Great team to death great company, so that kind of mindset was very important for me since the beginning. I really felt that in order for me to have a chance and compete with people that had a much better education that studied in their place. This isn't came from bigger cities.
I would need to work much harder in order to compete and I didn't treat that as a fairness on anything is just how life is so I can cry about it. What I can do something about it. So I salute you do something about it. So, this was the mindset that I had throughout my career. I also met a few important people. In my career, people that Inspire, I saw how they were. So I trying to surround myself from people that were an inspiration to me.
And I don't want to say successful, because success, we would need to Define what Sesame. And that means different things to different people. I surrounded myself of people that I was inspired by, so I always try to get closer to those people. And that doesn't mean famous people within every organization. There are people that you look at, it's like, wow, this person here is very interesting. I admire her knowledge or where she is and stuff.
So I always try to be closer to those people and stuff. Thanks through one of my majors are even describe that in my book. He was a very important person and he made me realize that I he's not as good as I thought it was and I had to work hard and be humble. So, for me, it was a very important relationship. Another thing that was important for me words to be in the right place as well. It's fine to be as good as you want to be but being the right place helps.
So for example, moving to London was probably one of the most important things that happened in my career. This was my dream. I wanted to go to London, but for example, if I was doing the things that I'm doing in London, if I was doing in the middle of nowhere in Brazil, I would not have The career progression, I had. So being the right place surrounded by the right, people
also helps you with your career. And I said, London is a great place for be, of course, across the world that are many other great places to be. But certainly when I came from was not one of them and then again competing in London or competing in Singapore in New York or in California. It's not easy, right? So there's a lot of very smart people well-educated people. So you need to bring your game. You need to make sure that you are aware. So yes. Spend nights and weekends and
holidays. Everything is studying and trying to be as good as you can. How can you come to love and then compete with people coming from Oxford from Cambridge? When you had a very poor education, you just need to put more effort to work hard. That's how it works. Another thing was be involved with communities, that communities. I think that this is another
huge part of my career. Probably one of the biggest the moving to London was the biggest, but also, as soon as I arrived, I immediately got involved with the local community. Inches because with the communities, you'll find a lot of very passionate people that are changing the industry people that are passionate. They're creating Frameworks. They're creating different ways of working their debates. They state of the industry and trying to improve this state of things.
And so for me that initial Connection in London was very important. And as I was part of some communities, I felt that there was something missing in the communities here and that's when I came across off the craftsmanship. So I had been following Uncle Bob Auerbach marketing for a very long time. All the extreme programming people. Fowler. Most of people inspired my career and I try to get closer to them. I also felt that we didn't have a software, craftsmanship
Community here. So I created one. This is another thing, like so you don't complain when certain things are not happening. You just go and do it. So if something doesn't exist, you to go to create, so being part of communes, and then, later on create in the cross machine community in London, which was the first in Europe, was massive because it allowed me to meet a lot of interesting people. But most importantly, I always say that we are limited by our own ignorance, right?
I'm limited by my words. I cannot go beyond my own ignorance on my own. It's a very slow process. But if I want to go beyond my ignorance, I need to collaborate with people. I need to talk to people need to understand what they know in absorbed. That's how we go beyond your own ignorance and communities, give you that. So that was important. And then there were two other things that were important, what you do for companies where we have a good life.
Diversity of work but still workers and employers. So I work for consultancies most of my career that gave me a huge exposure to many different projects and companies and Technologies, but still working for similar companies. And so that was good for me. And, of course, the latest thing that was for me, the biggest turning point was creating my own company, that completely changed my perspective of everything because it's very easy for you as an employee.
To be complaining about things. You complain about your manager, that is not good. So for me as it is, Everyone was not good. Right? So just developers were good. But manager was rude. I can understand what those guys were doing. Running that company. How they could not see such a problems, but I never looked from their perspective. So creating my own company made me look at it from different perspectives because now my own money.
So now, like, I don't have a boss or I don't have a manager to complain about if some things are not working. It's my fault. There's no one else that I can blame. I am the one paying the salaries now, so that gives you a completely different perspective. When approached those bags with a client is not happy. I'm the one to deal with that. I'm the one to blame for that. So these gives you a completely
different perspective. So those were for me, important things in my career, there really helped me to grow as a profession. Thanks for sharing that it's been a very wonderful Journey. From Brazil went to London, started a community, the London software, craftsmanship, Meetup group, and then, including writing the book which you haven't mentioned and also starting your own company, so Maybe you can tell us a little bit more about coder, ins your own company. What does coherence do?
So we are software consultancy company and we help clients to build software and to lean on modernizing our software as well. So what we try to do with could you not see state that Community spirit that group of people passionate about softer and create a company with those values? So could you know, seized private or well-structured Community? It is founded by developers, run by developers of The craftsmanship at its heart. Like most of the things I wrote
in my book. They are the code units. DNA. So, basically, that's what we do. We have today 100 people. We have three officers and we work with a variety of clients, in different projects, trying to bring across machine and build well-crafted software portals clients. I know that you have written a book about it, but for those of the listeners, who haven't heard about software craftsmanship, can you probably help to Define? What do you think is software
craftsmanship? So it's very difficult to Define. Our friendship. I think I offer like 34 different. Definitions depend on which context. Dependent which perspective on come from. If you have to try to find for me, sort across the shapes of Elf professionalism software development, but this is a very vague definition because we need to Define professionalism style. So by definition, like everyone that is paid to do. A job is a professional so that doesn't help much for me.
We need to go a bit deeper, the history of craftsmanship, starts with the history of agile. For those of us that stuck in the 90s. We were in a bad place. Place, the internet emerging mid-90s, and everyone was trying to figure out how to do software software became cheaper. Because before the night is softer, was a very expensive Hardware was expensive and stuff. So all of a sudden with the PC and internet structure was everywhere, software was growing to a degree that was
unimaginable before. But with that, we have also a very amateur industry, a very young and a mature industry. Well, we were trying to apply over the waterfall or a very strict engineering work. So agile came along and brought a different way of working that was more appropriate for the vast majority of the software project being created in the late 90s early 2000s. Most of us were extremely excited to be larger. I was massively excited because
I leave the pre agile area. You should give some background as a single thing. But Johnny's for the umbrella of methodologies, like the way I summarize it. Our duty is shortening the feedback loop and as you shorten your feedback loop, you get more information. Or more often and then with that information, you want that? What you were doing? That's for me. That's how I summarize our job. And then there are multiple
methodologies. Mean they're like from scrum which are driven development to Kris told you extreme programming and priest was like, the pragmatic programmers guys. So there are quite a few things that together, they formed their job. So I joined started as a developer's movement and we were all massively excited and one of the key things were developers will be closed for business.
And we would work in a short fast pace and it was also very focused on the technology and pieces working together. And so on. So there was a blessing and a curse at the same time, from one of the agile methodologies became massively popular, and that was good for agile because it's crammed helped. A judge should be disseminated across the world, but ice cream is also more.
Digestible were more appealing to managers, most technical deep and I anticipate extreme programming was not Slowing the growth of scrum. So agile start growing but not in a unified way. It's crown and the process side of agile, grew way faster than the technical side of her job. And that creates the friction within their Joy of Founders,
the 17 guys. So even they themselves had issues and people like myself that came from stronger technical background that was more focused on the extreme programming side, that life described. I like all the other methodologies, so I'm not here to say that. About scrum or any other thing, but the technical side was left behind. And what agile? We came a few years later was not what that original group. Attended. Our joy of today is seen, as well.
As a management is a way to manage project, is a way to manage people to have him back in terms of the business, but it's not technical. The reason I'm saying that is because this is key to justify. Why software craftsmanship exist, software craftsmanship, was a reaction to the evolution of our job. So we started with Robert Martin, where Bob Martin or Uncle Bob as most people know him and a few others, including myself. We would have disappointed. So the Mosin need to try to
restore the balance. You bring those technical practices back into agile software. Craftsmanship was born as a movement in Chicago, and I was the first one to bring them to Europe in terms of a community. There were other people, like Jason warm on Ricky calm. A few other people were talking about prosthetic, but I was the first one to actually create a community instead.
Sharing those engines, start, one of the things, the salt across the street movement was trying to do is, first of all, bring the extreme programming. In terms of agile practices. We like all data practices, but the one that we value the most is Extreme program. So that was one side, but that's more on the practice side. What's craftsmanship also brought to the table was, what I was saying, now back into the professionalism and pride. So he's making sure that you as
a developer. You should be proud of what you do. We are all contributing to the world. World. We can look at the world today in. Look at 25 years ago. We didn't even have internet, but they would just go to our phone and you buy food at 3:00 in the morning. This didn't exist in the past and we created that. So the sense of being proud of being a developer, being a developer doesn't career instead of just for a few years and then move to management.
I'm a developer by Heart by trade and I want to progress to develop. So this was important. And then another thing that for me was part, of course, my ship is what we call the career ownership, you own your career in it. Don't let companies or people to dictate what you learn when you learn. So like this is me. This is my career. This is my future. I should only partially investment. So those are the things for me professionally, pragmatism price.
As I say in my book. Those are for me, the mindset of software craftsmanship. That's what property brings to the table. And in terms of technical practice. We like quite a few extreme programming being the main ones, but we like the main reasons. I really like microservices, hexagonal, architectures are many things to be like, but there is the mindset and the receptor Actresses, their separate. Think it's pretty clear. It's a beautiful explanation.
I like the way that you brought up the history, why it was initially born because for those young enough to know about a gel and software craftsmanship itself. We didn't probably know much about why agile was born. And then there was this scrum, it becomes popular. And now it becomes a little bit of backlash towards Crown because of the management and the processes behind it. And why we need another one, which is called the software craftsmanship, towards more technical practices and
pragmatism. I also So that's this software, craftsmanship, Manifesto. I don't know who wrote that is. That also part of the principles behind software, craftsmanship. So my first song was written by some of the guys from a flight to the guys that really started at moving. These cargo based company where Uncle Bob was involved back. Then, one of the founders was his son. Michael, Marty. And those guys with Uncle, Bob called a bunch of people when they were defined, this of the
craftsmanship. They felt that they needed a Manifesto for those of you. That don't know the agile. Manifesto. That was great in 2001, Uncle Bob with Alistair cockburn. And Martin Fowler. They together, put a list of people that they invited. Like I think there were 25 people but only 17 were able to make it. So they went to a ski resort in Utah. And after two and a half days, they end up with their giant seven years later in Chicago, because Bob was part of the original one.
He was the one that helped to create a delusional manifest as they were trying to make a point. So, across machines became almost as a reactionary movement. You really try to make a point and poker Jai repeat at the beginning. In the beginning. There was that friction between craftsmanship and agile. The same way that we had with lean. So lean agile, craftsmanship as they emerged as movement. They were all having bickering with each other, but they felt that there was a need to evolve
a job. So if you look at the cross machine, 21st it built on top of that, diary takes their giant money faster than goes one step further. I felt that if you take the We into account when that happened. That was the right thing to do. Because we needed something that was strong, that would question. They stay crisp or then we question the direction of our job. So there was a need for our betterment, Festival that
Express the values. So, for example, we not only working software but well-crafted Soldier. So for me, we are making a statement because working software, it was an evolution back then. Because I think they say not only documentation but also working softer, something like that. And we said, okay, it's not only working software. We have everywhere. If I want to every company today and see those Abominations, those huge horrible codebase,
they work somehow. So we want more so not only work by well-crafted and then we have a few other things. Like I study on volume. We brought the Collegiate professionals. But again, it is a different historical moment as well. Agile was trying to make a clear distinction between what we had before before it was waterfall. Well structure separation of Business and Technology separation of requirements and Elopement and Analysis and architecture and testing everything was separate.
So the German festival was fixing that problem. So we were now just taking what agile fixed and the phone. So then we talked about the convention professions and productive Partnerships. But again, I think that it was important have the manifesto that expressed what the movement was about. But as we always evolved, I feel that the cross-ownership manifesto is important but not as important as it was, the giant manifest for the Giants. What's been really clear distinction of what we had
before. And what we had up the craftsmanship, just build a little bit on top and now I see a giant lean cross for sheet. And we had a few New Movement. You can take devops as another one. They all understand where they sit and how they all contribute to the same goal. But I think that we are all in good terms. Now, answer, you met a couple of times about well-crafted software. What is a well-crafted software some questions. So I would really hate to give any He very specific definition
of that and I'll explain why. Because as soon as you try to make a very precise definition, you stifle Innovation, but there are certain things that Army general principles are important. For example, scope that we are not scared to change. I would love to go to my code base and be comfortable not only myself but any new developer that comes in there. As soon as they come in the code clearly specifies, what it does. There's a good match between the
the technical implementation. And the business requirements we can see like July. So for this something domain-driven design brains very well, the ubiquitous language the main Mario and contacts, and all that. Good knowledge. So for me, this is one aspect as I speak to mine to the business. People being product owners or whoever they are business analysts. I can see those conversations that terminology in the code is very clear. When we change one part of me.
Don't break the other so that comes into coupling and cohesion at all levels, like, from the very low level. Love a function of the class. But all the way up to services in again, in domain driven design. We talk about bounded context and things like that. So that clear code organization that match the business testable. Nothing gives you more confidence than making a change. Pressing a button.
In a few seconds. You have a green bar with a red bar and when you have a red bar, you know exactly know precisely what was broken. This way of working for me is amazing. It makes you happy and you always hear that you are in control. You are. Nicole's not the other way around. And I remember, for example, one of the key things that was part of the interview process. When I start my career was how well we knew our debugging tools, because debugging was a very important thing.
That's how we found B, how you fix stuff. I cannot even remember, last time I had to debug a piece of code, but is not in the code that we start writing ourselves. If you are dealing with legacies, of course, you need to debug in understand a few things, but see for me like those are aspects that confidence that procedures. Should should get on with your job without being blocked by the
code itself from. He's an aspect of well-crafted coat, the new developer should learn the code very fast, the speed of our new developer, joining the organization, assuming that they understand the technology itself with that, understand how fast. They pick up the code base, that's for me, an aspect of well-crafted code. So those for me are more general terms. Now, I'm a preferred to be at that level. If you go choose specific. I think that we will be stifling
creativity. I'm actually old enough to play around with debugging tools as I still remember those days. I like the definition of in control that you mentioned. So it's like we are always in the control and we are not like scared touching the code or even looking and reading the code base. It's like sometimes there's this part of some Legacy code base. Nobody really wants to read and it's like probably long and super tedious and super complex.
So yeah, I can understand and I like the definition of in control. So for those people, for those developers who are new to the industry or who are still probably I think what would be your advice to start with this software craftsmanship? Because one of the problem I see in the industry is that in the company not every company Advocates. This as part of their probably, you know, like what conduct or maybe professionalism conduct. So for those developers, how can they start adopting this
craftsmanship mindset? First of all, we need to distinguish the mindset of a softer cross person. So today, we normally, like, you suffer cross brush across people as a general term, but like when I refer to myself a call, Men, so for me, there is a mindset of across person and there are the technical practices and they are not the same thing. In fact, they are very different things.
So when you say for someone to start with that, we start with the mindset, it's completely up to the individual. There's absolutely nothing. Nothing blocking you, there's no company. No one that will block how you think how you behave. So these anyone can strategically is like owning your career trying to be as good as You can be feel good about the profession that you have. This is our thing that I always talk about.
For me. There is a difference between having a professional having a job for me. This is significantly different. Our job is something that you do. Go your paid for into a profession is part of who you are is not a separate entity. When I say like, I am also crossed when it's part of what I am. I am a software developer. If you don't like the soccer custom software developer program or whatever you call it, but it's part of who you are.
I'm a doctor, an engineer and Lawyer is part of you, you are getting. This is a profession. I work for certain company. That's a job. And these for me is an important distinction for me. The mindset of our stuff across person is having a profession. He's making sure there is part of who you are. And even when it's part of who you are, you want it to be good. You don't want a part of you to suck to be bent towards that were not proud of. So when it's part of you you
wanted to be good. You want to Probably about that. So that's the mindset of across person. These can you can start to meet you. Now, there's a completely separate conversation is how do I bring certain practices or even the mindset should organizations that I work for and that's a very different conversation and here there are many different kinds of advice is because the device will also vary according to the context
that you're running. But there is some general advice, a question that I cannot even imagine how many times I was asked was Like how can I convince my team or my manager or my organization or whoever to do tdd? I cannot even count. How many times I was asked this question. So here, the important thing is not the TD. B is, how do you convince someone to do something? That is really, the key thing is
all about it is about anything. So then you need to think about, first of all, put yourself in someone else's position. So let's say I come to you and say, hey, harry, you know, everything you've been doing in the past, for the past, whatever country to you. They're being history. Yeah, you've got it wrong. Henry. You don't work. Well, you are not professional Henry, you need to do what I do. I don't know how you would react
to that. But if you were telling that to me, I would be very upset and I was certainly not listen to you at all. I would probably be quite rude to you and this is the problem because some developers that they say, I want to convince other people to do something, they come in with an attitude. They come in with an attitude that they are better than everyone else, that everyone
don't do things. Because Cuz they are stupid, or they haven't seen the light as they, and these kind of attitude will never allow me to drive technical change. So for me is all about if I want you to drive some technical change. First of all, let's make sure that I'm good at it that I can lead by example, because my first time I've seen attempts where people said, no, I want our team to do TG and then someone else. Okay, so can you show us in our real code base?
And the person was massively slower could not do that thing properly. Okay, you are asking me to change the way I work, which I feel good. Active to do something that you yourself cannot do. Well, it's not going. So, first of all, try to be good at what you are proposing. And then going there, not to talk about easy because in these are solution to a problem, a lot of the times that we're driving that can go change.
We want to convince people to adopt a solution that they might not understand what problems they're solving. And I think that this is where we should come from. So first of all, help people to understand, do we have a problem here? That this Signature proposes, a solution for, and then take people on a journey with you. So now, let's be greedy. I can be nice products. We can even break anything or speed up our delivery life
cycle. So be able to release more often, or not find bugs way down the line and then we have to rework those things a month later that we thought we were done. So as we start discussing those kind of issues, there is a lot, how can you prevent those things around? Maybe we could write about later test. Okay. That sounds a good. You should you write that before or after we go to code. Well, that's not reconcile. Malaysian Pastor starkly, then we evolve.
So this is from ey suggestion. When you're driving any technical practice, any that can go change focus on the problems first and make sure you can lead. By example, make sure that you know what you're talking about because if you are not good at what you are trying to convince other people to do that. It's a very big chance that you're gonna find another things that mindset across my cheek mind, such as creating a learning organization.
And in there, there are also a lot of advanced don't be blocked by your manager because your manager doesn't want to give you time or because they don't give you the money or they don't buy the books and stuff. Look, I believe that you have a one-hour Notch, right? So most countries will have a one-hour Bunch break. Take one hour a week.
After lunch time. Bring some lunch from home or buying a supermarket as most sandwich, go to an empty meeting room and tell your colleagues and say look guys. I'm going to be in this meeting room during my Each time. I'm going to be working on this Captain. I'm going to be learning these technology. Would you like to join getting fine people? So you don't need authorization for managers, you don't need
time. You know, like when you speak to your colleagues about whatever you like music sports or whatever, you have it, nice conversation. It can also have about sculpture. You can also have the constantly I learned this new technologies, new programming language. The more you do that your organization more people, get excited. They want to be part of that group. They wanted to learn some of my colleagues are learning. They are R. That's for me.
Like one advice and also don't try to convince everyone. Not everyone will join. So don't be upset about it. We have to about the ones that joint. He will never change. Everyone be acting with the ones that you can change. That's my advice. So for those listeners, we just listened to Sandra is pretty insightful. So you can start anytime you want. It's just a mindset. Anyone can not block your mindset, definitely, in terms of practices. Don't talk about solution first.
So try to come with what problems you are, trying to solve things. Through the Journey and probably proposed the solution from there. And then lastly, you probably cannot convince everyone and either that you must convince everyone, right? So there will be some detractors and it's fine. So the key thing here is that keep on learning and improve yourself. So Sandra, thanks so much for the software craftsmanship discussion. I also realized that lately you have been talking about software
modernization. A lot with your company called Durance. So what do you mean by software modernization? Actually, so I lost really find this option one. Ization as a continuous process of improving systems that are strategic in order to increase business agility. That's how I see that. So software, my ization is about improving systems that will create an impact in the business because it is a strategic effort, is not just a small refactoring, or adding some
tests. That's how I probably would Define softer condensation. So, how does it differ with software re-architecture or rewrite? You know, those kind of stuff. So I think that the architecture, we arrived are things that you do during a software modernization that you may do. Because for example, you can also talk about re-platform. Maybe you are taking your systems and now moving to the cloud or changing the cloud or what happened.
So those are things that you end up doing as part of a modernization process, but for me, the difference is the softer modernization is a business investment. It's like, look, we as a business, we want to go in this direction. And so are we ready to go in a direction we have systems? That would support the direction that we want to go or even like, are there anything blocking us
to move in that direction? So, first up with those in efficiencies where if we actually got rid of those in efficiencies, we will have more time and wanted to spend where we should spend at least a stoppage of the pieces and making sure that our technology is supporting, that stuff is so for me. The modernization is all about that is aligning the technology to support the business touch and in doing so, We might need to repack form a few systems.
You might need to react effectively Seasons. We might need to change the features from one system to another. So that is all part of the work of the mineralization is the business approach where refactoring and reactivities Technical approach. That might be used during a modernization project. Is it fair to say? I mean, based on my understanding is that you can only deal with software modernization as a certain scale.
I mean like you don't count refactoring adding more test something that it called modernization. But it's more towards like, okay, at this certain scale, the business wants to run in a certain direction, but probably they can't achieve that because of the software that they have, and thus, they need to modernize the system of the architecture of the software. Is that fair to say the assumptions? Yes. Yes, because most of us listening to the show.
We work a lot with Legacy code. So, not everything we do is new. Well, the new code is easy, likely to have to These need to be well designed and so on. So forth about the existing one, we need to refactor. We need you to keep improving as we are touching the different areas. This is something that we need to do as a normal part of our development cycle. When I talk about motorization is something that is more strategic.
You cannot do that. As your normal day-to-day job, the reasons we need to invest money. We need to prioritize, some people will be working certain things. So there is a whole business strategy behind the modernization. Then we are looking a few years ahead. You're not just looking at our next future. That's for me. How I see modernization projects. We are preparing. We are helping the company to restructure themselves for the
next few years, right? So in your experience, what are some of these business drivers may be some examples or maybe some categories of business drivers that normally companies consider for modernization effort. So there are few. What is what we call sustainable change. So, a lot of companies, I believe that all of the listeners will relate to this one. There is a general. Getting there. We are slow, that things are not
happening fast. From a developer's perspective, from a business perspective, from you a perspective. There's always someone has said, look, there is a lot of confusion seas, and we would like to be counting change, or changing our systems regularly in a good Pace. But as we are changing, we are pushing that out and stuff.
A lot of organizations. They have systems that are built in a way that this is not possible because they're not testable or the way that the system is architected doesn't allow different areas of the business to evolve independently. Don't be commanders. So you want to change the payment system battery pack the I don't know the products and the catalog and stuff, because they are all together that makes it cheaper to change or
difficult to test. That's why we need to have key way or because of the way that we deploy and do things. We cannot keep pushing things to production. So one of the reasons is that we may have a more sustainable change, but this is the still focusing on in efficiencies. That's a driver but it's a driver focused on clean efficiencies. Another drive. That isn't over. So companies say we would love to innovate more but it takes too long.
So every time you want to innovate our release Cadence this, you know, what's this is similar to the previous one, sort of because there are different aspects to it. One is, if you have a streamlined process, your software, your systems and infrastructure is all aligned. You can innovate faster, but there's also a different times that you don't even think that across the entire business. You might not really want to specific area.
Like, look, I don't you change. Everything is just this bit that you want to innovate. Once your system to allow that. So maybe there is another drive just to modernize that beat of the system may be like detached from the rest of the systems and making sure they're part of the system as an architecture, that allows us to innovate constantly and that has a different life cycle of the rest of the system. Another thing that is very interesting on how a talk is called lining product and
software design. So for example, it also depends on the kind of innovation and the kind of project speeds of your Imperial. Lean Startup. You need to push things up very quickly and then Get fit. So you first push this stuff out, get feedback and the new
barn and inspect. But in order to do that, we need to architecture system, to allow you to do that because you want, Push It Up. So the way that we collect information, you need to design your system in a way where that Cadence that read them is possible. So you need to notarize some companies. Prefer to innovate with very concrete features. They have a very stable set of coins and they release features
that our clients are asking for. So these has Different type of architecture, there is more stable refundable mind. There will be loads of people using that stuff and they've been waiting for that stuff. So, the way that you architecture system is different from the other one. So when you talk about Innovations, we also need to understand which kind of innovation so that we prepare our systems to support that and then there is technology.
For example, a lot of companies are spending a fortune, maintaining their in-house data, centers and production people stuff. So there is a lot of Technology of their Cloud technology, many things that would save them a lot. Money. A lot of time and we'll do a far better job doing inside or even testing Technologies or many other things. So those are some of them people culture something. Oh, please, don't talk much about. For example, a lot of companies say, oh, we are struggling to
hire. So we are struggling to attract and retain Talent. We know if you want a technology company you want to bring good technologists to your organization. You need to be working with good technology because good technologists. They want good technology. Sometimes the organization is all about that. We rely on technology and we need the best Minds to join us. Well, make sure that you want to know if your systems regularly so that you can keep them.
So those are different things but there are reasons a line is risk management. There are many other drivers, but those are just some of them, thanks for outlining all that. So to me, the company typical company, whenever people talk about software modernization, right? It's like a huge thing. It's very complex involves a lot of project planning resource planning. A lot of litigation process risk management and things like that. So in your experience, what typically are the common?
Maybe failures or impediments blockers that might prevent the success of the modernization effort. We are many blocks. You mentioned quite a few of them. I think that one of the blocks is trying to do too much in one go. I think that we should have a good goal. So for example, we should be ambitious when we talk about company strategy, where product strategy? We shouldn't be ambitious. We should look ahead a few years
ahead. So this is where you would like to be in a few years time and this Is where we are now. So, what we need to do to get there that Vision needs to exist. It doesn't exist. It needs to be created. Now. Once we have a Venus, okay. Now, we need to do all of that. This is what I would be against now, follow the agile approach. Okay. We have a vision. We have a go. We have a Direction. So now I can create that looking ahead a few years now, let's
reduce. So we know the direction we need to go. Let's reduce our vision to three months. What will be the next? The most important step forward right now? And then a plan for those new It's done for those six months during walk that you constrain will narrow down your focus. Just do a small things, do a few experiments. And as you do that, you start validating that direction that you created. So three months down the line after a milestone or three months, six months.
Whatever that Milestone would be you. Stoppin us. Okay, 36 months ago. We had this Vision in here and we were there. Now we progressed a little bit more. We like to be it. Do we still want to go in that direction? Ian, is this our main priority. So. Okay. Let's recalibrate that vision. And now let's prepare the next digit 0 to 6 months. Then you walk another three to
six months. Every so that's from either side could so then you don't go for this massive five-year monstrous projects that our organizations do that. Normally go wrong after 23 years. The people leave the company or they are promoted for something that has not been done. And then a new guy comes in and say, oh I want to change everything. I have a new five year. One. So then the lack of time, lack of money, lack of skills.
All of those things. The freak is block, is the fear of a big commitment money time, excusing in changes and stuff. So if you can remove the big Commitment, if you say like greater Visions mature commitment will be small three months. Six months. It's much easier to get started and keep review. So that would be for me then pageants and how I would mitigate those things. So, is there any kind of common principles behind? Find a successful software
modernization. You mentioned probably one is age of having more short feedback cycle, maybe three months. Instead of five year plans. Is there any other common techniques or principles behind a successful modernization? Yeah. So the main one is like I have a big Vision but working in small increments and keep reviewing the distress. What we discussed before. Another thing in an organization, a modernization project. It is an investment and with an investment.
You need to have a return which means that investment has a disruption. So that is money tying people, right? So that are involved in that investment. So one thing is make sure we have a clear measuring the return on investment but also try to create as minimal disruption as possible because the business to needs to keep going. So you cannot wait for freeze your business for one to three years. Okay. So you need to keep going. So having that balance is very
difficult. There is a lot of analysis and planning that goes in so that you can modernize our system while we fighting. Minimum disruption to the business as usual work. The thing is, don't try to fix, what's not broken. This is another thing that we see a lot, maybe when those kinds of initiatives come from technology. Like I need to be honest, some people in technology, they go to business, a we all need to go to
the cloud. We all need to do micro Services. We all need you to complication in nodejs or whatever, so they come in with all these Solutions, but what is exactly the business value that you're providing me doing that. So if it's not broken, don't fix it. And when I say, bro, I'm talking about business here. For example, not being able to deliver features fast enough because we have a long queue a cycling. A lot of reworking, our development flow. That's a business problem.
That's not a technology. So every technology problem is a business problem, but let's make sure that we can map that. Another thing is for me law of diminishing returns. This is similar to the potatoes log. So sometimes a 20% Improvement in one area, might cause an 80% Improvement. So if We fix 20% of our
technical issues. We might create an 80% Improvement in a business and it's not worth it sometimes to try to get your 100 percent because that's where the law of diminishing returns comes in. So in order to achieve the last change percentage of the reasons we need to do 80% of all working. So just focus on things that really caused an impact but it don't waste a lot of effort in case of have a very small and possibly very smart in how we
organize our work. And the last one that I would say is this took me a long time to figure out and this is Creaks chains, which is software, craftsmanship, movement, which I helped you create. You need to have Excellence everywhere and they are quite often. Are the fingers only need to keep refactoring one week later. They are still deciding, which named we're going to put it into
a variable. So when they keep refining the same class over and over again, this is for me a problem and the problem that we do that in a much larger scale, we services with architecture and stuff so part of the modernization. But also part of craftsmanship, which is more important to me is we should always strive for a pragmatic. Solution. And I have that as a subtitle of my book. That pragmatism is part of
craftsmanship. Pragmatism is different from cutting Corners. Pragmatism is to say look, given our context. What is the simplest thing you could do here? What is the best we can do? Even the context. But accepting that time is a constraint money is a constraint business. Moving forward is a constraint. So we did those real constraints
we can do our best. So then we Define a pragmatic solution and Dean, the pragmatic solution, we have accents, but Excellence needs to be bounded because when Excellence is not bounded for is unbounded. There is a big chance to technical. People will be very fast, very fast, very fast, and things try to improve things, but business-wise has zero business value.
So, this is something quite typical for every technical people or Engineers. We all love dealing with Technologies, especially if there's any new technologies, we need in the cloud contains. - kubernetes or even some kind of new methodologies. Like for example, if there's any new, I don't know, like XP coming around. We just want to play around, try it. And probably also resume driven development. You want to attack a certain label in our resume, right?
So what do you think can be done to improve our pragmatism? You know, like how can we adopt more pragmatics approach rather than being enticed by new technologies or shiny Technologies. This is just a question because for me is part of you need to want to do that as well. Then I Two side streets and one is the personal side of.
Yes, for example, you understanding that you are a professional, providing a service regardless, if you want a permanent employee, if you are a contractor or a consultant, it doesn't matter how you are hired to do that job. How your pages and job, you are still a professional, providing a sentence. And in my view, you should provide a service that suits your client. Well, regardless of your preferences, this is very
difficult. This is very common for people working Consultants accomplished to understand less common for people working as permanent employees. Because as a consultant you were hired to do specific jobs and you try to understand the coins context, their boundaries, the things that they keep comfortable diffusal. If you want comfortable, you have those conversations, you understand, real constraints, made up constraints.
And then, when you come up with your solution, you create a solution that fits that context, that doesn't mean that's how you do it yourself, so, Your hand. Just say if I have zero constraints, I would do this. And if I had a post my online and zero constraints, I would go this way. But here I'm providing a service. I would never do something that would hurt our clients, but I would also not push a solution to them that they're not comfortable with that's not going to work them.
So for me, this is the pragmatism from to place a tailor your Solutions given the context that you have. The mindset is, like, what would be best for the company? Not be best for me? So that's one side and on the other side. It's a bit more harsh know is from the ones that are paying the bill. I think that when you are paying for the service that you don't understand, that is a lot of problems. You are not educated enough to value that service.
We all do that. So there are lots of things we pay to data. I'm not educated enough to judge and this creates problems because my expectations might be different for the person, providing the service and may not be able even to hire the person providing the service. For example, now open we had to People do marketing and sales and really back office job that I don't know how to do myself and makes it very difficult for me to judge.
So I believe that organizations they need to educate themselves. A little bit better for the core systems for the course services that they hire for regardless, if they hire permanent employees or external nodes, but if a service is very key to their business, they should be well educated, so they can judge the people providing defense. That's another aspect. I know I might be idealist here. Right?
But if we have a well-crafted software, is it going to help in terms of avoiding the software modernization effort? Not necessarily know because for me it depends on how you define those things and in which level of abstraction you define those things at least. When I think about well-crafted software and thinking of this mole, let's say on the code base, that our services have. So is it where structure well-tested nicely separated? It's tough, but I'm not Cannibal
the entire solution. So for example, if we decide to have a new set of features business ones, or have a different direction, the way that my systems are designed with a split or even a technology that I use where we are hosting. Those systems might not be suitable to the direction. So it's not only related to the code itself. But the choice of the technology that contextual model, as the organization involves the systems were created to map. Those kind of things.
You know, areas are gone with context of the business, but the business is evolving at some point. What we created in the past might not be alive anymore. And that is regardless, if the code is Well, written for not saying with your technology and cloud and so on so forth. So for me, the modernization is now aligned the current Technical Solutions to the new direction of the company wants to go or remove some impediments that before worked.
Well, but now, with the new Direction, the way that we've done things in the past are now a block for where you want to be, definitely make sense. So, Sandra has been a pleasure talking about software, craftsmanship, and modernization. I have one last question, which I normally ask for every guest, which is to share your tree. Technical leadership. Wisdom. Do you have any tree technical leadership wisdom that you want to share with us today? I'll tell you what works for me.
I don't know if that's one thing that I always tell you to pass, but he became even stronger in the past two years, is a thing called Extreme ownership. There is a book called Extreme ownership, which is a book that I wrote. I read recently, and it really improved the way it was. And so basically, like what it means, is, whatever happens, is your fault. So you have no one to blame, except yourself. So, these mindsets just need to be careful because people may become depressed.
Whole we have coffee now. It's my fault. I'm just trying the world. It's not at that level. But when you are doing your job organization, when you see things that you don't like, or things are not going the way you want. First thing to think about is is your fault. What are you doing about it? What should I do it? Why am I failing to communicate? What am I failing to turn these around and you would never blame anyone else except for yourself. These for me is key for any
leader who take responsibility. Another thing is try to be as good as you can. In what to do. That doesn't mean that you're going to be great. That doesn't mean it's going to be better than anyone else. But you have that innate desire to be good. You are trying hard. These leads to potentially the third one that even though become an inspiration for me, a leader needs to inspire people begin to look at it. Even inside this person here, Works harder than anyone else.
So a leader should be the one working hard. The hardest should be the one calling the responsiveness. To say it's fucked up as my fault and work hard. So I think that, if you are trying to be as good as you can be, take full responsibility for everything. The last one would happen. Naturally. That is be an inspiration. I would say that would be my third advice, but now that I'm thinking about, you don't choose to inspire people, right? So you cannot choose that is not
under your control. Be an inspiration to others, you can Behave in a specific way and maybe people will feel inspired by that or not. So I will stick with you then. So extreme ownership and try to be as good as you can. Okay? How about another one? Be sure that you're nice to people. So thank you so much for the wisdom. Definitely. I can resonate with all that. So Sandra if people want to find you online, is there a place where they can find you? Yeah, so we can reach out to me
by email if they want. So Sundrop at coder in Stockholm. There's always Twitter varies. Sundra Mancuso. Those are probably the two best place for each option. Alright, so thanks again for coming to the show and sharing your knowledge and wisdom. I wish you. Good luck with Cody runs and all your modernization effort. My pleasure. Thanks for having me. Thank you for listening to this episode and for staying right till the end.
If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on the Episode page at technology, know the death website, including the full transcript, interesting quotes and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the show's mailing list on technology. No, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.