academic concepts for quality assurance

Many projects have big problems with quality assurance. With academic projects you even see some groups that invest large amounts of their working time in finding and fixing bugs most of which most likely would not have occurred if they had established a small amount of quality assurance. Many commercial software development groups have the very same problem in principle but they are forced to hold at least a certain internal quality level to prevent bankruptcy.

Most software developers don't like to do quality assurance because some parts of this work are boring. Especially academics often don't want to do work that is not directly involved with their topic. This is understandable because they cannot write shiny papers about this basic work and thus don't want to waste their time for it. Actually they often waste their time because if every developer in a development group does omit this work completely you get extremely broken code resulting in the situation that all developers in the group waste most of their time finding the same bugs. Because of the fact that fixing a bug takes more time than adding an ugly workaround, they often skip to fix the bug hurting their colleagues this way because they have to do the very same work for this bug as well. Often academics also have never learned how to use their development tools appropriately. For example many of them use revision control systems in a way that they check in their work no earlier than they think their whole subproject is complete. This results in lost revision history and many bugs when one decides to check in the work of the last four(!) months at once.

But there is a special sort of people that can drive me into a rage in such a situation. This sort is always reading the latest books about project management and quoting the smartest ideas from these books. Additionally they design new shiny test systems to improve the quality of the product ignoring the fact that they already have a huge amount of tests that work but nobody actually cares about their failing results.

When will those people learn that the work is not complete when you design and implement infrastructure tools. It is no earlier complete than you actually _use_ them.