Keep Defects from Escaping
Keep Defects from Escaping
Creating faster should not come at the price of bugs and errors, and detecting these bugs before they get out will increase overall value.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
Toyota did not start out as a car company. They started by making industrial looms for the creation of textiles. They became a leading loom manufacturer by building looms that required minimal human intervention because they recognized that an operator's time was expensive. If one operator could run a dozen looms instead of just one loom then production was far more cost-effective. This philosophy was quickly adopted by their customers and Toyota became a leader in automating loom operations. This philosophy is at the very core of Toyota, and when they started to manufacture cars, they applied very similar concepts.
One of the key differences between Toyota's method of manufacturing of cars and the traditional method was that traditional assembly lines tried to ensure quality through a series of rigorous inspections. But Toyota recognized that these kinds of activities were a huge waste. Instead, they put their attention on finding ways to prevent defects in the first place.
Every workstation on a Toyota assembly line has a big red button designed to stop the line. If your job is to bolt seats in a car and it looks like you're not going to be able to finish one before your car leaves your station, you push the red button. The first time you push the red button a manager appears and they don't reprimand you. The supervisor's job is to help you finish your task before the car leaves your station so the supervisor dives in and helps you finish your current task. If it looks like both of you are not going to finish the task in time, then you push the red button a second time and that stops the line so you can finish your task before the line resumes.
Stopping the line means the car will not leave a station until the job of that station is complete. It also means that no cars will leave any other stations because the entire assembly line is down. Because of this, there is no need for extensive inspections after a car comes off the assembly line.
Something else happens when an operator stops the line: everyone involved does a retrospective. The purpose of the retrospective is not to lay blame but rather to figure out how to improve the system so that the situation is never encountered in the future. In this way, Toyota is continuously improving and fine-tuning their process.
This may seem highly inefficient but in practice, the line does not stop very often.
This is a rich analogy that shows us how we can build software much more effectively. Traditional software development has a lot of similarities to traditional manufacturing. We often design, build, and test code in distinct phases. While this makes sense in the construction industry, it's very inefficient to apply these same concepts to creating software. Lean teaches us to detect defects early because it's cheaper.
Many years ago, I read a report from TRW that said if it takes one unit of effort to change a program in the design phase then it takes 67 units of effort to make that same change right before release. So we've known since the sixties that early detection is more cost effective but Waterfall methodology still waits until the end of the process to inspect and detect defects.
While early detection is cheaper than late detection, it's cheaper still to prevent errors from happening in the first place and this is what the practices of Extreme Programming are all about. With a good continuous integration server and reliable unit tests, we can catch defects as they're written so they can be fixed immediately and often with minimal effort. This changes the dynamic of development where both quality and velocity start improving.
Published at DZone with permission of David Bernstein , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.