[MUSIC]
In this lecture, we are going to learn about one of the principles of lean
software development card defer commitment.
And this principle addresses one of the issues of software development
where we decide when we know the least about the problem.
So what is it?
It's the ability to make commitment as late as possible.
And commitment about the architecture or some decision that we have to make.
So ability to make commitment as late as possible or
make decisions when you have the information you need to make the decision.
Before commitment does not mean that you just to delay the developments but
make the decision when you have the information.
So why does it matter?
Well, if you think about it,
we have to make lots of decisions when you are doing software development,
about the architecture, about the solution that you're building.
And as you are building your solution, you have more and
more understanding of user needs.
You have better understanding of your solution.
So if you make the decision about the solution earlier without having
that information that you have, let's say, two months later,
then it may be that the chances of the decision being wrong are higher.
And so when you make wrong decision about your architecture or your design,
of course it's going to be costly and of course we don't want it.
So that's the idea that if you can delay the decision until you have
the information you need or you really require that we can move forward
until we make the decision, I think that can eliminate a lot of waste [INAUDIBLE].
So that's the idea behind this principle is to defer your decision.
I think you have all the information or until it's really needed.
So the question is how do you defer decision?
So one of the concept in traditional project management is that you
sequentially develop your software like you do all of your requirements,
all of your design, all of your development and so on.
So in this case, what happens is that you have to make all of
your design decisions in this design phase.
So you don't have all the information.
And as we know that, we know less in the early phase of the software development.
So you make all your decisions in the early phase.
Whereas, during the development, all the things you're going to learn,
we don't have that information in the design phase.
So the idea is that, if you can develop in such a way that design development, all
of those things are happen concurrently, or at least in a smaller batches,
so that we can gain more knowledge before we have to make a decision.
It's going to help you defer commitment.
At a higher level basically, what we want to do is, we want the ability
to postpone decision until the last responsible moment or make it possible.
So if you can't do that, make it possible to make changes easily.
So the change decision can be digested effectively.
So for example, let's say you're building a website, and so
you need to make a solution what tool are you going to use for the web server.
So in that case, if you can build in such a way that whatever web server you
selected in the beginning you can change it later, easily that will be effective.
Because then you're really differing decision of finally which apps are you
going to use.