#25 - Software Craftsmanship & Modernization - Sandro Mancuso

Episode Introduction [00:00:53]

Henry Suryawirawan: [00:00:53] Hello, hello, my friends. It’s always great to be back here again with a new episode of the Tech Lead Journal podcast. I’m your host Henry Suryawirawan. As always, thank you for spending your time with me today listening to this episode. If you haven’t subscribed to the podcast, please take a few seconds right now to subscribe to the Tech Lead Journal podcast on your favorite podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, and many others. You can also find and listen to Tech Lead Journal on YouTube and make sure to check out different playlists that I have on the channel. Also do check out Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram where I posts interesting quotes and gists from each episode daily, and join 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 would also benefit from the contents from my amazing guests. 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 techleadjournal.dev/patron. Your kind support would 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 and the co-founder of Codurance. In this episode, Sandro 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 dived deep into discussing about software craftsmanship, how it relates to agile and the other software movements. And Sandro 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 moved 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, reemphasized 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 engineers from the rest. I also highly encourage you to read Sandro’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 podcast 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.

Introduction [00:04:59]

Henry Suryawirawan: [00:04:59] Hey everyone. Welcome back to another show of the Tech Lead Journal. 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 it was in 2015, if I’m not wrong. So again, very pleased to meet Sandro today. Sandro, welcome to the show.

Sandro Mancuso: [00:05:22] Hi, Henry. Thanks for having me. It’s a pleasure to be here.

Career Journey [00:05:26]

Henry Suryawirawan: [00:05:26] So Sandro, to start with, normally I would ask the career journey of my guests. So can you share with us maybe some of the highlights or turning points in your career?

Sandro Mancuso: [00:05:34] So I started my career about 25 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 in there. I think that I can share the things that I’ve judged important from this journey coming from a very remote place in a country that is not very well-known for technology to what I am today.

So one was drive. I really wanted to make sure that I would be good enough to work in good companies. So I always tried 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 as well. It’s also fine for everyone to want 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 wants to be part of a great team and stuff. But what do you offer to that great team? To that 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 better places, that came from bigger cities, I would need to work much harder in order to compete. And I didn’t treat that as unfairness or anything. It’s just how I face. So I can cry about it or I can do something about it. So I actually 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 inspired me. I saw how they were, so I tried to surround myself from people that were an inspiration to me. And I don’t want to say successful because success, we will need to define what success means, 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 that organization, there are people that you look at and so 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. And through one of my mentors, I even described it in my book. He was a very important person. And he made me realize that I was not as good as I thought I 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 was to be in the right place as well. It’s fine to be as good as you want to be, but being in 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 move to London. But for example, if I was doing the thing that I’m doing in London, if I was doing in the middle of nowhere in Brazil, I would not have had the career progression I had. So being in the right place, surrounded by the right people, also helps you with your career. And I think that London is a great place to be. Of course, across the world, there are many other great places to be. But certainly where I came from was not one of them. And then again, competing in London or competing in Singapore and 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 up there. So days and nights and weekends and holidays, everything’s studying and trying to get as good as you can. How can you come to learn 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 being involved with communities, tech communities. I think that this is another huge part of my career. Probably one of the biggest. But moving to London was the biggest. But also as soon as I arrived, I immediately got involved with the local communities. Because with the communities, you 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. They debate the state of the industry and try to improve the state of the industry. 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 software craftsmanship. So I had been following Uncle Bob or Bob Martin for a very long time. All the eXtreme Programming people, Martin Fowler. Most of the people that inspired my career. And I tried to get closer to them. I also felt that we did not 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 have to go and create. So being part of community, and then later on creating the craftsmanship 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 ignorance. 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. I need to understand what they know and absorb. That’s how we go beyond our own ignorance. And communities give you that. So that was important.

And then there were two other things that were important. Working for companies where we have a good diversity of work, but skilled workers and employers. So I worked 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 the developer, everyone was not good. Right? So just developers were good, but manager was rude. “Eh, I didn’t understand what those guys were doing in running that company. How they could not see certain problems.” But I never looked from their perspective. So creating my own company made me look at from different perspectives because now is 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 a project goes bad or a client is not happy, I am the one to deal with that. I’m the one to blame for that. So this gives you a completely different perspective. So those were for me, important things in my career that really helped me to grow as a profession.

Henry Suryawirawan: [00:12:09] Thanks for sharing that. It’s been a very wonderful journey from Brazil, went to London, started a community, the “London Software Craftsmanship”, a meetup group. And then including writing the book which you haven’t mentioned and also starting your own company.

Codurance [00:12:22]

Henry Suryawirawan: [00:12:22] So maybe you can tell us a little bit more about Codurance, your own company. What does Codurance do?

Sandro Mancuso: [00:12:28] So we are a software consultancy company and we help clients to build software and to maybe now modernize their software as well. So what we tried to do with Codurance is take that community spirit. That group of people passionate about software and create a company with those values. So Codurance is private or well-structured community. It is founded by developers, run by developers. Software craftsmanship as its heart. Like most of the things I wrote in my book, they are the Codurance DNA. So basically that’s what we do. We have today a hundred people. We have three offices and we work with a big variety of clients in different projects. Trying to bring craftmanship and build well-crafted software for those clients.

Software Craftsmanship [00:13:10]

Henry Suryawirawan: [00:13:10] 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?

Sandro Mancuso: [00:13:21] So it is very difficult to define craftsmanship. I think I offer like three, four different definitions, depending of which context, the pillar which perspective I’m coming from. If we have to try to define, for me, software craftsmanship is about professionalism software development. But this is a very vague definition because we need to define professionalism as well. So by definition, like everyone that is paid to do a job is a professional. So that doesn’t help much. For me, we would need to go a bit deeper. The gist of craftsmanship starts with the gist of agile. For those of us that started in the nineties, we were in a bad place. The internet emerged in mid-nineties and everyone was trying to figure out how to build software. Software became cheaper because before the nineties, software was very expensive, hardware was expensive and stuff. So all of a sudden with the PC and internet, software was everywhere. Software was growing to a degree that was unimaginable before. But with that we had also a very amateur industry, a very young and amateur industry. Well, we were trying to apply of 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 projects being created in the late 90s, early 2000s.

Most of us were extremely excited with agile. I was massively excited cause I lived the pre-agile era. Just to give some background, agile is not a single thing. Agile is an umbrella of methodologies. Like the way I summarize it, agility is shortening the feedback loop and as you shorten your feedback loop, you get more information more often. And then, with that information, you adapt what you were doing. That’s for me, that’s how I summarize agile. And then there are multiple methodologies in there, like from Scrum, Feature-Driven Development to Crystal to eXtreme Programming, and principles like the pragmatic programmers guys. So there are quite a few things that together they form agile. So agile started as a developers movement, and we were all massively excited. One of the key things were developers will be close to the business. And we would work in a short, fast pace, and it was also very focused on the technology and business working together and so on.

So that was a blessing and a curse at the same time. Scrum, one of the agile methodologies, became massively popular. And that was good for agile because the Scrum helped agile to be disseminated across the world. But Scrum is also more digestible or more appealing to managers. Most technical deep agile discipline, eXtreme Programming, was not following the growth of Scrum. So agile start growing, but not in a unifying way. Scrum and the process side of agile grew way faster than the technical side of agile. And that creates the friction within the agile 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 liked the Scrum. I liked all the other methodologies. So I’m not here to say bad things about Scrum or any other thing. But the technical side was left behind. And what agile became a few years later was not what that original group intended. Agile today is seen as more as a management. It’s a way to manage projects. It’s a way to manage people to have feedback 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 exists. Software craftsmanship was a reaction to the evolution of agile. So we started with Robert Martin or Bob Martin, or Uncle Bob, as most people know him and a few others including myself, we were disappointed. So there was a need to try to restore the balance, to bring those technical practices back into agile. Software craftsmanship was born as a movement in Chicago. And I was the first one to bring that to Europe in terms of a community. There were other people like Jason Gorman, Enrique Comba, a few other people worked open up craftsmanship, but I was the first one to actually create a community and start sharing those ideas.

At the start, one of the things the software craftsmanship movement was trying to do is first of all, bring eXtreme Programming up. In terms of agile practices, we like all the other practices, but the one that we value the most is eXtreme Programming. So that was one side. But that’s more on the practice side. What craftsmanship also brought to the table was what I was saying now back into the professionalism and pride. So it’s making sure that you, as a developer, you should be proud of what you do. We are all contributing to the world. If you look at the world today and look at 25 years ago, we didn’t even have internet. Today, we just go to our phone and we buy food at three o’clock in the morning. This didn’t exist in the past, and we created that. So this sense of being proud of being a developer. Being a developer as a career, instead of just for a few years, and then moved to management. I’m a developer by heart, by trade, and I want to progress as a developer. So this was important.

And then another thing that for me was part of craftsmanship is what we call the career ownership. You own your career. You don’t let companies or people to dictate what you learn, when you learn. It’s like this is me. This is my career. This is my future. I should own it. I should invest in it. So those are the things for me. Professionalism, pragmatism and pride, as I say in my book. Those are, for me, the mindset of software craftsmanship. That’s what craftsmanship brings to the table. And in terms of technical practice, we like quite a few, eXtreme Programming being the main one, but people like the Domain-Driven Design. And we like microservices, hexagonal architecture. There are many things that people like, but there is the mindset and there is the practices. They’re separate things.

Henry Suryawirawan: [00:18:54] 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 agile 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 Scrum 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.

Software Craftsmanship Manifesto [00:19:22]

Henry Suryawirawan: [00:18:54] I also saw there’s this Software Craftsmanship Manifesto. I don’t know who wrote that. Is that also part of the principles behind software craftsmanship?

Sandro Mancuso: [00:19:31] So the manifesto was written by some of the guys from 8th Light. The guys that really started that movement is a Chicago based company where Uncle Bob was involved. Back then, one of the founders was his son, Micah Martin. And those guys with Uncle Bob called a bunch of people. When they were defining the software craftsmanship, they felt that they needed a manifesto. For those of you that don’t know, the Agile manifesto that was created 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 2.5 days, they ended up with agile manifesto. Seven years later in Chicago, because Bob was part of the original one. He was the one that helped to create the original manifesto. As they were trying to make a point, so the craftsmanship became almost as a reactionary movement. They really tried to make a point and poke agile a bit at the beginning. At the beginning, there was that friction between craftsmanship and agile. The same way we had with lean. So lean, agile, and craftsmanship, as they emerged as movements, they were all having bickering with each other. But they felt that there was a need to evolve agile. So, if you look at the craftsmanship manifesto, it builds on top of agile. It takes the agile manifesto, and it was one step further.

I felt that, if you take the history into account, when that happened, that was the right thing to do. Because we needed something that was strong. That would question the status quo. That would question the direction of agile. So there was a need for a better manifesto that express the values. So personally for me, not only working software, but well-crafted software. So for me, we are making a statement because working software, it was an evolution back then. Because I think that they say not only documentation but also working software or 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 code base. It worked somehow. Right? So we want more. So not only work, but well-crafted. And then we have a few other things like steadily adding value. We brought the community of 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-structured, separation of business and technology, separation of requirements and development and analysis and architecture and testing. Everything was separate. So the agile manifesto was fixing that problem. So we were now just taking what agile fixed and evolved.

So then we talk about the community of professionals and productive partnerships. But again, I think that it was important to have the manifesto that expressed what the movement was about. But as we all evolved, I feel that the craftsmanship manifesto is important, but not as important as it was the agile manifesto. The agile manifesto was a really clear distinction of what we had before and what we had now. The craftsmanship just build a little bit on top. And now I see agile, lean, craftsmanship and we have a few new movements. You can take DevOps as another one. They all understand where they sit and how they all contribute to the same goals. But I think that we are all in good terms now, I’d say.

Well-crafted Software [00:22:44]

Henry Suryawirawan: [00:22:44] You mentioned a couple of times about well-crafted software. What is a well-crafted software?

Sandro Mancuso: [00:22:49] That’s a very good question. So I would really hate to give any 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 for me general principles are important. For example, it’s code that we are not scared to change. I would love to go to my code base and be comfortable in not only myself, but any new developer that comes in. That as soon as they come in, the code clearly specifies what it does. There’s a good match between the technical implementation and the business requirements. We can see like-to-like. So for this something like Domain-Driven Design brings very well the ubiquitous language, the main module, and the bounded context, and all that good knowledge. So for me, this is one aspect. As I speak to mind to the business people being product owners or whoever they are, or business analysts. I can see those conversations, that terminology in the code is very clear. When we change one part of it, don’t break the other. So that comes into coupling and cohesion at all levels, like from the very low level of a function in the class, but all the way up to services.

And again, in Domain-Driven Design, we talk about bounded context and things like that. So that clear code organization that makes the business testable. Nothing gives you more confidence than making a change, pressing a button, and a few seconds, you have a green bar, or a red bar. And when you have a red bar, you know exactly. You know precisely what just broke. This way of working for me is a nice. It makes you happy. You always feel that you are in control. You are controlling the code, not the other way around. And I remember for example, one of key things that was part of interview process when I started my career was how well we knew our debugging tools. Because debugging was a very important thing. That’s how we found bugs. How you fix stuff. I can not even remember last time I had to debug a piece of code. At least not in the code that we start writing ourselves. If you are dealing with legacy, of course, you need to debug and understand a few things. But see, for me, like those are aspects that confidence, that being suggested to get on with your job without being blocked by the code itself. For me is an aspect of well-crafted code. A new developer should learn the code very fast. The speed that our new developer joining the organization, assuming that they understand the technology itself. We then 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 might prefer to be at that level. If you go too specific, I think that we will be stifling creativity.

Henry Suryawirawan: [00:25:23] I’m actually old enough to play around with debugging tools. So 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.

How to Adopt Craftsmanship Mindset [00:25:47]

Henry Suryawirawan: [00:25:47] So for those people, for those developers who are new to the industry or who are still probably growing, 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 work conduct or maybe professionalism conduct. So for those developers, how can they start adopting this craftsmanship mindset?

Sandro Mancuso: [00:26:11] First of all, we need to distinguish the mindset of a software craftsperson. So today we normally like to use software craftsperson, craftspeople as a general term. But like when I refer to myself, I call craftsman. So for me, there is a mindset of a craftsperson 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 there to block how you think, how you behave. So this, anyone can start immediately. It’s like owning your career. Try to be as good as you can be. Feel good about the profession that you have.

This is another thing that I always talk about. For me, there is a difference between having a profession and having a job. For me, this is significantly different. A job is something that you do. You go, you’re paid for what you do. A profession is part of who you are. It’s not a separate entity. When I say like, I am a software craftsman, it’s part of who I am. I am a software developer. If you don’t like the software craftsman, a software developer, a programmer or whatever you call it, but it’s part of who you are. I’m a doctor, I’m an engineer and I’m a lawyer. It’s part of you. You are the thing. This is a profession. I work for a certain company. That’s a job. And these for me is an important distinction. For me, the mindset of a software craftsperson is having a profession. It’s making sure that is part of who you are. And 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 bad, or that you are not proud of. So when it’s part of you, you want it to be good. You want to be proud about that. So that’s the mindset of a craftsperson. At least, you can start immediately.

Now there’s a completely separate conversation is how do I bring certain practices or even the mindsets to the organizations that I work for. And that’s a very different conversation. And here, there are many different types of advices because the advice will also vary according to the context that you are in. 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 TDD bit. It’s how do you convince someone to do something. That is for me, the key thing. It’s not about TDD. It’s 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 Henry, you know everything you’ve been doing in the past. For the past whatever, 10-20 years you have been in the industry. 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 would certainly not listen to you at all. I would probably be quite rude to you. Right? And this is the problem because some developers that they’ve said, I want to convince other people to do the same thing. 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 they are stupid or they haven’t seen the light as they have. And this kind of attitude will never allow you to drive technical change.

So for me, it’s all about, if I want 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 like, for example, I’ve seen attempts where people said, “No, I want our team to do TDD.” And then someone else, “Okay. So can you show us in our real code base?” And the person was massively slow and could not do that thing properly. “Okay. You are asking me to change the way I work, which I feel productive. To do something that you yourself cannot do well.” It’s not going to work. So, first of all, try to be good at what you are proposing. And then go in there not to talk about TDD. Because TDD is a solution to a problem. A lot of the times that we’re driving technical change, we want to convince people to adopt the solution that they might not understand what problem 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 thing that we’re proposing is a solution for it. And then take people on a journey with you. So now that we agree. Yeah, it can be nice for us if we didn’t 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 kinds of issues. Then say like, how can you prevent those extra hour? Maybe we could write some automated tests. Okay. That sounds like a good idea. Should we write that before or after we build the code? Well, let’s start writing some automation tests to start with, then we evolve. So this is for me, my suggestion. When you’re driving any technical practice, any technical 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’s a very big chance that you’re going to fail.

Another thing is the mindset. The craftsmanship mindset is creating a learning organization. And in there, there are also a lot of advice. 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 lunch, right? So most countries will have a one hour lunch break. Take one hour a week at your lunchtime. Bring some lunch from home or buy in a supermarket, a small 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 lunchtime, I’m going to be working on this kata. I’m going to be learning this technology. Would you like to join?” And invite 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’ll have that nice conversation. You can also have about software. You can also have that conversation. “Hey, I learned this new technologies and new programming language.” The more you do that in your organization, more people get excited. They want to be part of that group. They want to learn. Some of my colleagues are learning there. 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. Be happy about the ones that join. You will never change everyone. Be happy with the ones that you can change. That’s my advice.

Henry Suryawirawan: [00:32:38] So for those listeners who just listened to Sandro. It’s 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’re trying to solve, take them through the journey and probably propose the solution from there. And then lastly, you probably cannot convince everyone, and neither 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.

Software Modernization [00:33:07]

Henry Suryawirawan: [00:33:07] So Sandro, 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 Codurance. So what do you mean by software modernization, actually?

Sandro Mancuso: [00:33:20] So I like to define software modernization as a continuous process of improving systems that are strategic in order to increase business agility. That’s how I see that. So software modernization is about improving systems that will create an impact in the business. Because it is a strategic effort. It’s not just a small refactoring or adding some tests. That’s how I probably would define software modernization.

Henry Suryawirawan: [00:33:48] So how does it differ with software re-architecture or rewrite, you know, those kinds of stuffs?

Sandro Mancuso: [00:33:54] So I think that re-architecture, rewrite are things that you do during a software modernization. That you may do. Because for example, you can also talk about replatforming. Maybe you are taking your systems and now moving to the cloud or changing the cloud or whatever. So those are things that you end up doing as part of a modernization process. But for me, the difference is the software modernization is a business investment. It’s like, look, we as a business, we want to go in this direction. So are we ready to go in that direction? Do 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, for example, with those inefficiencies, where if we actually got rid of those inefficiencies, we would have more time and money to spend where we should spend. That is the strategy of the business of making sure that our technology is supporting that stuff. So for me, the modernization is all about that. It’s aligning the technology to support the business stuff. And in doing so, we might need to replatform a few systems. We might need to re-architect a few systems. We might need to change the features from one system to another. So that is all part of the work. But the modernization is the business approach where the refactoring and re-architecture is technical approach that might be used during the modernization project.

Henry Suryawirawan: [00:35:11] Is it fair to say, I mean, based on my understanding, is that you can only deal with software modernization at a certain scale? I mean, like you don’t count refactoring, adding more tests, 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 or the architecture of the software. Is that fair to say the assumptions?

Sandro Mancuso: [00:35:36] Yes. Yes. Because like, I feel that a minor refactorings and adding tests are just part of your normal development. I believe that 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. Like we need to have tests, these need to be well-designed and so on and so forth. But the existing one, we need to refactor it. We need change 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 side. When I talk about modernization, it’s something that is more strategic. You cannot do that as your normal day-to-day job. The business will need to invest money, will 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 feature. That’s for me, how I see modernization approach. We are preparing. We are helping the company to structure themselves for the next few years.

Modernization Business Drivers [00:36:32]

Henry Suryawirawan: [00:36:32] Right. So in your experience, what are some of these business drivers, maybe some examples or maybe some categories of business drivers that normally companies consider for modernization effort?

Sandro Mancuso: [00:36:43] So there are a few. One is what we call sustainable change. So a lot of companies, I believe there are a lot of the listeners will relate to this one. There is a general feeling that we are slow. That things are not happening fast from the developer’s perspective, from a business perspective, from a QA perspective. There’s always someone to say, look, there is a lot of inefficiencies. And we would like to be adding change or changing our systems regularly in a good pace. So as we are changing, we are pushing it 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 from others. So we want to change the payment system. But it will impact the, I don’t know, the products and the catalog and stuff, because they are all together. That makes it difficult to change or difficult to test. That’s why we need to have QA. 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 still focusing on inefficiencies. That’s a driver, but it’s a driver focused on inefficiencies.

Another driver is innovation. So companies say, " We would love to innovate more. But it takes too long." So every time we want to innovate, our release cadence is, you know, so is this 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 sign is that you don’t innovate across the entire business, you might innovate in one specific area. Like look, I don’t want to change everything. It’s just this bit that we want to innovate. But your systems don’t allow that. So maybe there is another drive just to modernize that bit of the system. Maybe like detach from the rest of the systems and making sure that part of the system has 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, I have a talk, it’s called “Aligning product and software design”. So, for example, it also depends on the kind of innovation and the kind of project speed. So if you are a lean startup, you need to push things up very quickly, and then you get… So you first push the stuff out, get feedback, and then you learn and inspect. But in order to do that, you need to architect your system to allow you to do that. Because you aren’t pushing that out. So the way to be collecting information, you need to design your system in a way where that cadence, that rhythm, is possible. So you need to modernize. Some companies prefer to innovate with very concrete features. They have a very stable set of clients and they release features that their clients are asking for. So this has a different type of architecture. That is more stable. Every time you go live, there will be loads of people using that stuff, and they’ve been waiting for that stuff. So the way that you architect your 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, our companies are spending a fortune, maintaining their in-house data centers and production people stuff. So there’s a lot of technology out there, cloud technology, many things that would save them a lot of money, a lot of time. And we’ll do a far better job than doing inside or even testing technologies or many other things. So those are some of them. People and culture, something that companies don’t talk much about. For example, a lot of companies say, “Oh, we are struggling to hire.” So they’re struggling to attract and retain talent. Well, if you are a technology company and you want you to bring good technologists to your organization, you need to be working with good technology. Because good technologists, they want good technology. Sometimes the modernization is all about that. We rely on technology and we need the best minds to join us. Well, make sure that you modernize your systems regularly so that you can keep them. So those are different things, but there are business aligned with risk management. There are many other drivers, but those are just some of them .

Common Modernization Impediments [00:40:37]

Henry Suryawirawan: [00:40:37] Thanks for outlining all that. So to me, in a 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 mitigation 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?

Sandro Mancuso: [00:41:02] There are many blocks and you mention 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 you talk about company strategy, or product strategy, we should be ambitious. We should look ahead, a few years ahead. So like, this is where we 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. If it doesn’t exist, it needs to be created. Now once we have the vision, so 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 goal. We have a direction. So now that we’ve created 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 would be the next, the most important step forward right now? And then we plan for those three months or for those six months. Then you work on that. You constrain, you narrow down your focus. Just do a small thing, 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 stop and it’s okay. Three, six months ago, we had this vision in here and we were there. Now we progress a little bit more. We learnt a bit. Do we still want to go in that direction? Is this our main priority? So, okay. Let’s recalibrate that vision and now let’s prepare the next three to twelve to six months. Then we work entire three to six months.

So that’s really the cycle. So then you don’t go for this massive five-year monstrous projects that a lot of organizations do. That normally go wrong after two or three 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 plan.” So then, the lack of time, lack of money, lack of skills, all of those things. The biggest block is the fear of a big commitment in money, time and skills in changes and stuff. So if you can remove the big commitment. If you say like greater vision, but your commitment will be small, three months, six months. It’s much easier to get started and keep reviewing. So that would be for me, the impediments, and how I would mitigate those things.

Principles of Successful Modernization [00:43:19]

Henry Suryawirawan: [00:43:19] So is there any kind of common principles behind a successful software modernization? You mentioned probably one is agile, 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?

Sandro Mancuso: [00:43:36] Yeah. So the main one is like have a big vision, but working in small increments, and keep reviewing the business. That’s what we discussed before. Another thing in a modernization, a modernization project, it is an investment. And with an investment, you need to have a return, which means that an investment has a disruption. So there is money, time, people, right? So they 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 minimum disruption as possible. Because the business still needs to keep going. So you cannot wait or freeze your business for one, two, three years, and 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 your systems while with very minimum disruption to the business as usual work.

Another thing is, don’t try to fix what is not broken. This is another thing that we see a lot. Mainly when those kinds of initiatives come from technology. Like I need to be honest, some people in technology, they go to business, say, “We all need to go to the cloud. We all need to do microservices. We all need to do an application, Node.js.” Or whatever. So they come in with all these solutions. But what is exactly the business value that you’re providing in doing that? So if it’s not broken, don’t fix it. And when I say broken, I’m talking about business here. For example, not being able to deliver features fast enough because we have a long QA cycle and a lot of rework in 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 Pareto’s law. So sometimes the twenty percent improvement in one area might cause an 80% improvement. So if we fixed 20% of our technical issues, we might create an 80% improvements in the business. And it’s not worth it sometimes to try to get to a 100%. Because that’s where the law of diminishing return comes in. So in order to achieve the last 20% improvement to the business, we need to do 80% of our work. So just focus on things that really cause an impact and don’t waste a lot of effort on things that have a very small impact. So be 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 it out. And this is a criticism to the software craftsmanship movement, which I helped to create. We need to have excellence everywhere. And they are quite often are the people that say, “Oh, we need to keep refactoring.” One week later, they are still deciding which name they’re going to put in their variable. So when they keep refactoring the same class over and over again. This is for me a problem. And the problem that they do that in a much larger scale, with 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 given the context?” But accepting that time is a constraint. Money is a constraint. Business moving forward is a constraint. So within those real constraints, we can do our best. So then we define a pragmatic solution and we deemed the pragmatic solution, we have excellence. But excellence needs to be bounded. Because when excellence is not bounded or is unbounded, there is a big chance that technical people will be refactoring, refactoring and refactoring things, try to improving things, but business-wise has zero business value.

Improving Our Pragmatism [00:47:11]

Henry Suryawirawan: [00:47:11] 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, be it in the cloud, containers, 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. We want to tag 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 pragmatic approach rather than being enticed by new technologies or shiny technologies?

Sandro Mancuso: [00:47:47] This is a difficult question because for me, it’s part of you need to want to do that as well. There are two sides to it. And one is a personal side, I guess. For example, you understand that you are a professional providing a service. Regardless if you are a permanent employee, if you are a contractor or a consultant, it doesn’t matter how you are hired to do that job, or how you’re paid to do the job. You are still a professional provider in a sense. 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 in consultancy companies to understand. Less common for people working as permanent employees. Because as a consultant, you are hired to do specific jobs and you try to understand the client’s context, their boundaries, the things that they feel comfortable, the things they feel uncomfortable. 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 in your head, you say, if I had zero constraints, I will do this. And if I had, it was my own money and zero constraints, I would do it this way. But here I’m providing a service. I will 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 with them. So for me, this is the pragmatism coming into play and tailor your solutions given the context that you have. The mindset is like, what would be best for the company? Not the best for me. So that’s one side.

And on the other side, it’s a bit more harsh now is from the ones that are paying the bill. I think that when you are paying for the service that you don’t understand, there is a lot of problems. You are not educated enough to value that service. We all do that. So there are lots of things that we paid today that I’m not educated enough to judge. And this creates problems because my expectations might be different from the person providing the service. I may not be able even to hire the person providing the service. For example, now our company, we had to hire people doing marketing and sales and many in back office jobs that I don’t know how to do myself. And it 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 core services that they hire for. Regardless if they hire permanent employees or externals Well, if a service is very key to their business, they should be well-educated so they can judge the people providing the service. That’s another aspect.

Well-crafted Software & Modernization [00:50:21]

Henry Suryawirawan: [00:50:21] 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?

Sandro Mancuso: [00:50:30] Not necessarily, no. 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, I’m thinking on this mode. Let’s say on the code base that our services have. So it is well-structured, well-tested, nicely separated and stuff. But I’m not thinking about the entire solution. So, for example, if we decide to have a new set of features business-wise or have a different direction, the way that my systems are designed were split. Well, even the 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, the architectural model. As the organization evolves, the systems were created to map those kinds of functional areas, the bounded contexts of the business, but the business has evolved. And at some point what we created in the past might not be aligned anymore. And that is regardless if the code is well-written or not. Same with new technologies and cloud and so on and so forth. So for me, the modernization is now aligning the current technical solutions to the new direction that the company wants to go. Where we move 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 we want to go.

3 Tech Lead Wisdom [00:51:50]

Henry Suryawirawan: [00:51:50] Definitely makes sense. So, Sandro, it’s 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 three technical leadership wisdom. Do you have any three technical leadership wisdom that you want to share with us today?

Sandro Mancuso: [00:52:05] I’ll tell you what works for me. I don’t know if that’s going to work for other people. One thing that I always had in the past that became even stronger in the past two years, is a thing called extreme ownership. There’s a book called “Extreme Ownership”, which is a book that I read recently and it really improved the way I do things. So basically what it means is whatever happens is your fault. So you have no one to blame except yourself. So this mindset, you just need to be careful because people might become depressed, “Oh, we have COVID! Now, it’s my fault. I’m destroying the world.” It’s not at that level. But when you are doing your job in an 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, it’s your fault. What are you doing about it? What should I do about it? Why am I failing to communicate? What am I failing to turn this around? And you would never blame anyone else except for yourself. This for me is key for any leader. You take responsibility.

Another thing is, try to be as good as you can in what you do. That doesn’t mean that you’re going to be great. That doesn’t mean if you’re going to be better than anyone else. But you have that innate desire to be good. You are trying hard.

This leads to potentially the third one that you end up become an inspiration. For me, a leader needs to inspire people. They need to look at the leader and say, “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 responsibilities and say, “It’s f***** up. It’s my fault.” And work hard. So I think that if you are trying to get 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 it, you don’t choose to inspire people. Right? So you cannot choose that. It’s not under your control, be an inspiration to others. You can only behave in a specific way, and maybe people will feel inspired by that or not. So I will stick with two then. So extreme ownership and try to be as good as you can. Okay, I’ll add another one. Be sure that you are nice to people.

Henry Suryawirawan: [00:54:05] So thank you so much for the wisdom. Definitely, I can resonate with all that. So Sandro, if people want to find you online, is there a place where they can find you?

Sandro Mancuso: [00:54:12] Yeah, so well, they can reach out to me by email if they want. So it’s sandro@codurance.com. There’s always Twitter, that is @sandromancuso. Those are probably the two best places to reach out to me.

Henry Suryawirawan: [00:54:25] All right. So thanks again for coming to the show and sharing your knowledge and wisdom. I wish you good luck with Codurance and all your modernization effort.

Sandro Mancuso: [00:54:33] My pleasure, Henry. Thanks for having me.

– End –