&#62; Either they don't sufficiently understand the problem  scope, they're overworked, or they're just lazy and don't bother running through enough of their own quality controls before releasing changes.<p>The number of possible system states in larger systems can be enormous. I feel like to have this opinion, perhaps you have worked mainly on smaller systems? In larger systems, there can be so many possibilities that it would take several times longer to test than to code, and without reading spec docs, it is very difficult to tell what correct even <i>is</i>.  For example, a student loan system I worked on fit this bill.  The glib answer would be to say it was so complex because of poor programming, but that's not true.  The legal reality it was modeling was complex and so the software could not be less complex than the underlying system's rules.  I have worked on several such systems in different industries.<p>Now, you could argue that all programmers should become programming/QA people, but that would be self-defeating as programmer time is generally more expensive per-hour than QA time.  Further, the type of person who is good at running through 400 steps of detail-oriented rote testing is not always the same person that you would like doing high-level design.  Specialization makes life more efficient. Even if they did happen to be the same person, if they enjoyed one task more, why wouldn't they go to a job where they could focus on that type of task?