Hey, a quick message, for those of you who are listening to this
episode on Spotify, I have a small favor to ask Spotify.
Now allows mobile users to rate podcasts, I would really
appreciate it. If you can take a quick pass to
go to the technique Journal podcast page, and leave your
favorite show, your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
Today's clip is from package, you know, episode 100, With day
Farley the one who runs the popular continuous delivery,
YouTube channel, and also the author of continuous delivery
and the latest book, modern software engineering in this
clip. They've explained his view on
Modern software engineering and why it emphasizes on the
practices for building better software faster.
They've described the foundations of the software
engineering discipline, and explain the core competencies.
We need to succeed by becoming experts at Learning.
For today, we will discuss mainly from your latest book,
which is titled modern software engineering.
The first thing that comes to mind for me, when I look at the
title, why do you call it modern software engineering?
Is there the old ways of software engineering?
And there's a new modern way of software engineering?
We are able to talk with stuck in my mind for a long time.
While I was writing the book and to be honest I was somewhat
nervous like the reason why I call it modern Subterranean
rather than just software engineering and I was nervous,
oblique white least kind of the same.
I think. Now industry, we kind of weirdly
devalued, what we think of as engineering.
I think it's very common to think for people to say,
software development isn't engineering and a lot of it
isn't that think that's fair and not get, isn't engineering, but
in other disciplines engineering doesn't mean heavyweight
bureaucracy, which I think is what it tends to mean to us.
What engineering means in other disciplines is the most
effective efficient by you're doing work of high quality.
And so if software engineering doesn't allow us to build better
software faster, it isn't software engineering.
So modern software engineering, I think he's different to what
we're before we tried to implement engineering approaches
before and they were nearly all one is narrowly focused on some
particular set of tools or diagramming techniques or
something like that and bureaucratic and heavyweight.
And that's not what I mean at all.
So, I mean almost entirely the opposite of that.
So what are you? Interested in politics by
background and interests. My hobbies is that I'm very
interesting science. I think that a reasonable
definition of engineering is as a practical implementation of
science. You apply scientific style
reasoning, which is Humanity's best approach to learning to
solving practical problems. And I think that's a reasonable
kind of colloquial. Definition of engineering.
I was always interested in those kinds of ideas.
What are the ID that we could point?
Point two and whatever your technology, whatever, the
problem you're solving, I don't organization that your work.
If you applied these principles, you have a better chance of
success. And I thought I'd spotted some
of those things over time and they related to continuous
delivery which was my previous book that I worked on with Jay.
So humble and so on. But also somewhat separately.
The slightly different angle. It's kind of all cargo they
intersect and they're very reinforcing at one another but
they're not the same idea. So what would the principles
that would allow us? To do a better job.
And I thought that was what I was trying to explore, and
that's what the title is meant to try.
And convey the subtitle of the book itself is doing what works
to build that the software faster.
And in your book I also find it quite insightful.
Is that you mentioned that if our software development
practices do not allow us to build better software faster, we
should really change them because they are not engaged
during. So please tell us more about
this concept. Why do you think so?
Why we should focus on building better software faster?
The simple answer is, why would anybody want to build were
software slower? I think it's the combination in
car. This is my corner.
Again, colloquial take on the Dora metrics, the metrics that
come out of the state of debauchery court.
That give us a predictive model, if you work in these kinds of
ways and do these kinds of things, you increase your
chances of success and they are based on the stability met X.
What's the quality of our software?
When we introduced our current production, how often does he
break? And when it breaks, how long
does it take us to recover from the breakage and throughput?
What's the efficiency with which we can deliver software of that
quality? So that's the faster part.
So working quickly, one of the findings from the door and
metrics which is important, I think is that there is no
trade-off between speed and quality.
One of the traditional assumptions is that if you want
to build high-quality, Things, you need to go slowly what
Medora report says is know, if you'd go slowly, you build
lower-quality things and that's what the statistics say.
That's what a sociological approach to measuring the
performance of subdued. Lot of teams finds the more
barriers you put into being able to release change quickly, the
worse the output. So we want to be able to move
quickly, we want to be able to go faster, and we want to be
able to build better software, and that means that we need to
be able to focusing on be able to learn, find out where
mistakes are To in really quickly and efficient and that
kind of these, one of the ways we displayed in with continuous
delivery, can you still use a fantastic way of being able to
build better software fast from my career itself?
I can tell that there's so many experience from my view, is that
we build software faster in the beginning, but since that, after
a long period of time, or maybe few months, it starts to get
slower and slower. And maybe many people have left.
They don't know about the context that domain problems.
So, I think maybe some of the tools that we will discuss today
can help people to really build better software faster like
continuously. So, you have a definition about
software engineering, right? If I can read here, is that the
application of empirical scientific approach, which you
mentioned in the beginning, just now to finding efficient
economic Solutions. So, the economic Solutions here
is also quite interesting to practical problems in software.
I know that you'll cover in the book that some of these keywords
are really important. Maybe if you can discuss
slightly some of these terms, why do you think it's important
to Define software engineering using Sweet.
So, I was trying to get the simplest minimal description of
what I was thinking. In terms of engineering.
I was quite pleased with that description that you just read
out because it's fairly lean. It's fairly concise, but I think
he doesn't miss anything important.
So applying the reasoning, the rational approach of science, I
think that one of the fundamental nature of science is
that the difference is between science and almost.
Everything else is that we start out assuming that we're probably
wrong and that's a very Healthy thing to do in engineering, and
in such a development at all. So we're going to apply
scientific style thing in a lightweight, not overburdening,
not bureaucratic way. But we're going to be informed
by that kind of thing. We're applying at solving
practical problems. We're not doing theoretical
researcher. Proving the quarks are the
basics of particles or anything. We're building things.
And so we've got to be practical and pragmatic.
So the empiricism of engineering just trying stuff out,
ultimately, it is a big part. Well, the economic part is
Again, part of engineering. If we are physicists, we can
imagine building machines at a black hole, thinking about that
practically economically in energy terms.
We're not ready to do that kind of for us Engineers.
We are building things and so there are always economic
Straits at some level. That's about the amount of time
and effort and money that they spent, but also economic
constraints in the sense of the performance of our delivery.
Assistant and the performance of our software, the carbon
footprint of the software that we create, that kind of thing.
He's an interesting question for you need sewn, right?
So I wanted to get that in there as well.
So I think all of these different parts of the
definition, kind of leaders in this direction of trying to
organize our thinking in a more rational way and apply it to
solving problems, and are of value to people in some way.
That's what I was trying to reach full with the definition.
Thanks for that explanation about the software engineering.
So, I think for us, we need to probably redefine some of our
understandings of engineering is not just writing code that works
and deploy it. I think that's a really good
point. One of the things that are
obsessed with at the moment, he's watching SpaceX build their
space Rockets to go to Mars. That's engineering Live on
YouTube, you can kind of watch it happening in the real world,
that's not theoretical. They're evaluating their ideas,
their blowing spaceships off are learning from that.
They're making progress. My step and I think all of these
things kind of coming to an engineering approach to solving
problems and thinking about the ways in which stuff can go wrong
and all of the time looking at out of he proved and refine our
designs and a solution so that they'll better fit.
The problem that we're trying to try to solve.
For us to follow this definition of stuff, engineering you
mentioned there are two things that we have to be expert at.
So one is actually to become expert at learning.
This comes back. Probably to the scientific
approach that you mentioned. If s is experts at managing
complexity, maybe we can cover one by one.
Let's start with experts at learning.
So you mentioned there are a few key things like five things that
we need to be able to practice in our software engineering or
software development day to day. So what are those five things?
Yes, so experts learning, let's just like War I that support,
first of all it's to do with this kind of scientific
engineering philosophy of assuming that we probably wrong,
we not going to start out with perfect vision.
We're not going to be able to predict the business context,
the technical context, the socio-technical context of how
we organize ourselves to what, we don't know the results, and
you both think at some level, we're going to get all of those
things wrong. And so we want the ability to
make progress while we Open the at the start of the project
where we don't have all of the answers yet.
Therefore we want to optimize to be able to learn Microsoft, did
some research into their own ideas and found that two-thirds
of their ideas produces zero or negative value for the company.
Single black female to learn which with a bad idea.
So early on, if you wanted to be efficient.
So we want to optimize for Gail to learn all sorts of things.
What the problem is that we're really trying to solve what our
users really need to have to solve that problem.
Why technical In fits. Does it really work?
Is it releasable? Is it comply?
All those things? You'll learn ways of doing that.
Are we going to work in order to be able to do that?
As you said, there are five principles that underpin, our
ability to do that. So, we need to work iteratively.
We need to working many small steps so that we have many
opportunities to connect. Look at what it is, the v2e and
refine it. Oh that didn't work.
Let's not do that anymore. That kind of thing.
We need to take feedback seriously.
We need to understand what information.
Should we need to gather in order to help determine whether
our ideas or our Solutions are useful for help?
Whether our products are landing with our customers, where there
are tests are passing or failing, we want to optimize
great feedback to do that. We want to also be able to work
incrementally, want to be able to build systems or almost
evolutionarily. So, it's a bit by bit knots.
All in one, great, big chunk. So we want to be able to deal
with these things more independently so that we can
kind of car be as in certain if we working on big.
Scale divide up the work so that different parts of the
organization can work on different parts of the problem.
So working incrementally is part of all of that we want to work
experimental e. If you want to start being more
scientific, be more like engineers in our approach.
Then we should apply a little bit of discipline around the way
in which we think about making changes.
And the key to that for me is to think experimental e.
We want to make little predictions.
You want to say? Well this is the problem that we
are. Looking at the moment we think
if we did this thing this would improve that position on this
problem. How would we tell?
Whether that thing was and wasn't working, that's the
difference between an experiment into that step of predicting,
what the outcome is. And then carrying out the tests.
So you could think of this as a etched with the product.
We think that if we do this thing, it's going to improve the
sales or this region and will put it into production.
See what happens or you can. Give it as a test.
I think that the coach should do this thing.
If it were to do this thing, this is the assertion that I
would be able to make. Then I write some code to
fulfill that assertion, these are ways of it working
experimental e and that can. And for me has become pervasive.
That's the way that I now think about and practice nearly all
change where I can. So what is it that I'm trying to
do? How would I understand the
results of this thing? And I'm just thinking in that
way, doesn't need to be heavy weight, can be really Really
short really efficient but it's just a slightly more disciplined
organized. Way of structuring, I think that
gives us better results and the last one is the empirical we
already talked about your cases and Engineering is about
real-world things. It's not about some Ivory Tower
imagination of a system. It's about the reality of it.
So we need to gather feedback from production.
We need to go to understand what's really going on.
We need to be able to make practical decisions based on
what it is that we find Elon Musk is building space.
Setting check this. I'm sure that they're doing very
sophisticated computer simulation, but at some point it
builds the beds of metal and that they blow it up on a test
and see how it works. That's how Engineers speak and
that's how they operate. If you look at the developments
on any sophisticated end in think about an aeroplane
aeroplanes used to be incredibly dangerous things in 2017.
The equivalent of two, thirds of the population of the planet
flew in commercial airliners and One person died that wasn't
possible in the early versions of ever played.
We have to go through that pain of things breaking and killing
people. And so, when we won't do that
anymore, will relearn. So 8 is about what incrementally
and growing, and learning based on mistakes that we make
fundamentally. And we've got to give ourselves
that freedom to be able to operate that way and to make
those kinds of mistakes books when they occur to learn from
them and to correct them. So I think those five things its
roots If working feedback, incrementalism experimentation
and empiricism are the Cornerstone of our ability,
previous, a species to be able to learn effectively and
efficiently. I can't imagine anything that we
could consider to be engineering without those things.
So the first third of the book is really about exploring.
Those ideas in much more detail in looking at each one of those
principles and kind of picking apart and seeing how it fits
with software development. I hope you enjoyed this short
clip from pagli Journal favorite playlist.
If you find this episode useful, please help.
Share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you want to listen more from this conversation, please
go back and listen to the original full conversation with
my guest, stay tuned for the next technology, no episode.
And until then goodbye.