Scientific components are coming

Reliability is even more of an issue for scientific programmers than it is for other programmers. Since the correctness of a program is relative to its specification, the greatest difficulty of scientific programming is that the specification for a program is almost always an abstract mathematical or physical statement, not something specific. The way scientific programmers most frequently verify that their programs are correct is to examine their results on a series of problems that have known solutions. Since the program must be prepared to solve a general problem, it produces only an approximate answer to a specific problem. It takes judgment to decide whether the program is operating correctly-that is, if the differences between the actual and desired answer are a result of numerical noise, the approximations chosen, inaccurate models of physical properties, or actual coding errors. Many bugs are indistinguishable from errors in modeling or deficiencies in numerical techniques. At worst, a bug may cause us to make an erroneous decision to revise a model or abandon a certain approach. At best, bugs can be found only through considerable effort. Scientists are slowly coming to appreciate the merits of OO languages, unit testing, sophisticated source control systems, and other modern techniques. From a scientist´s perspective, the most important thing about reusing a component is not the time saved, but the reliability gained