In this article, the author is talking about steps to take to actually reduce software defects in programs before release through several steps. The first step seems kind of obvious for a goal but nonetheless it is to stop believing that you can’t put out a program that doesn’t have defects. Defects are nothing more than simple mistakes that could have been avoided but were not, of which these bugs could be trivial or system breaking. So instead of believing that these programs are bound to release with problems and defects, aim to write your programs without any defects. Another thing the author points out is if you are given code to test, not to simply point the finger at the developer of the code being lazy. The people writing the code are not simply trying to skimp on their end to save their time. Instead they are often overworked and simply could have missed something. It is also explained in the article that often the first thing to be done for reducing defects is to develop unit test coverage. However, although this unit test coverage could cover most of the program, it could be ineffective. Something the author points out in his article is the concept of “bug bash” which doesn’t seem like in the end it would be very productive. It is the idea where a team takes the software and tries to break it, and then repair it. While this may provide more knowledge of the software, it seems this kind of practice would be a focusing too much on the knowledge of the software instead of getting a product out to clients. Finally, some of the things that are pointed out in the article is to try to avoid tendencies that will lead to errors in the first place. These sort of tendencies could be things such as when copy and pasting from files, missing some small statement, or could be having files that may be too complex, leading to inattention errors.