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.
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.