In this lecture,

we're going to learn about another lean principle called build quality in.

And what we mean by that is not to defer

quality checks to a specific development phase like,

sometimes we do all the development and then do all the testing in one of the phases.

So, instead of that,

we want to build quality from the very start and every step.

So, as we are building, we are making sure that it is defect-free or

defects are being detected and corrected and

the quality is right from the very beginning in the code.

And what this does is that instead of tracking defects,

we're trying to prevent defects.

So, why is it important?

Well, if you see defects,

defects is something that will cause you to fix it

and it's not really something useful code.

So, it causes waste, and then,

if you're continuously have the quality in, then,

and you're finding the defect on a regular basis,

that means that any time there is a defect found,

it is easier to find,

because you only need a little bit of change.

So, you know where the defect came from,

and then since you made the change recently,

you know what code you recently changed,

so it's easier to fix also.

And it also helps you measure true progress.

So, lot of times,

what happens if you have the testing in a specific phase,

we say, "Okay, the development is done and design is done and requirement is done."

So, that means we are x percent done.

But then, when you get into the testing, you realize, "Oh,

it's not even what we were looking for or there are so many defects."

And then it remains in that 75% progress for a long time.

Whereas, if the quality is built in all the time,

then whatever is complete,

we measure the true progress of the project, and then sometimes,

if you have a defect which is not detected and still in the code,

it can cause other defect to be hidden because of that other defect,

so it can cause something called defect masking.

So, what can you do to build quality in your software?

One other thing is having defining the standards.

And so, what that does is that if you're defining

coding standards and many other things the way you're operating,

it reduces the conversion waste,

so that nobody has to interpret if the things are inconsistent,

then this means the same thing as the other thing.

If everybody is following the standards,

then they don't have to do that conversion in their mind,

then style A is same as style B.

But of course, it has to be used,

whatever standards you have define,

it has to be used to be useful.

The another one is code reviews, so,

if you do your code reviews again before you commit to your code,

you are having someone to make sure that you did the right thing.

And so, you are again kind of emphasizing that quality is

built in and any defect is found during the code reviews.

Another concept which is common is called pairing,

where instead of one developer working on a code,

there is a pair of developer who is working on

the code and so there is this constant discussion and constant,

you can say, a code review happening on the fly.

And what has been found is that when you're doing this type of coding,

then the quality of the code is very high.

Another one, you can talk about is mistake proofing which basically,

if you're doing a lot of steps in

any part of the development process and you're doing that manually,

if you can automate it,

it reduces the chance of making a mistake.

So, mistake proofing is automating any of

the manual steps that you are doing in your development process.

Another way is automated test which is,

anytime you commit a code,

you run all these steps,

which are automatically run,

will detect any defect that was created by recent commits.

So, that can also helps you build the quality all the time in the code,

because anytime you commit a code,

that's being tested and any defect is found right away.

Another concept is called test driven development where you write your test first,

make them fail, and then you write your code and make your test pass.

So, what really happening is that you know that

your tests are correct and as well as your code is correct.

So again, this is another way of making sure that the quality is built in.

Another one is continuous integration which is continuously integrating your code with

the rest of the code so that anytime you commit a code,

it's validating that it didn't create any other defect at any other places in the code.

And then, last but very important is to

build the awareness and importance of quality in the team.

So, if you take a look at the manufacturing wall in the lean manufacturing,

they empower all the team members to look at the quality and if they detect anything,

they are empowered to stop the whole production unit.

And so similarly, in software development,

we can build this awareness and empower the team members to raise concerns.

If they see anything around quality,

raise the hand and get that fixed.

So, here are a lot of different ways you can build quality in the software,

so that you don't have to find defects or track defects,

but you can prevent defects.

Build Quality In

Lean Software Development

Meet the Instructors