"Lux, James P" <[EMAIL PROTECTED]> writes: > But there's a lot of "hidden process" in building high quality > software that the consumer (the physicist in this example) doesn't > need to be aware of. An engineer building a bridge needs to know > the properties of steel, and have some understanding of how steel is > made (so the properties of various kinds fit in a context), but does > NOT need to know how to run a foundry or rolling mill.
True, and a physicist using computers need not understand things like how to design processors or how to manufacture DRAM. > Likewise, I wouldn't expect a scientist to have to know how to > manage a software development project, Here I disagree. The analogy is broken -- the engineer uses pre-made steel and can just know its properties as sold. The scientist is not using pre-made software and the way it gets made is intimately linked to success. The paradigm you are implicitly holding to is still one which detaches the two fields of "computer people" and "science people", operating on the assumption that we can have scientists that do not know computers who are handing off requests to a computer team that does not understand science. That is just not a recipe for success. Tim Cutts mentioned in an earlier message that he has repeatedly improved software performance by over two orders of magnitude and once by seven. You don't get those sorts of fixes if everyone involved doesn't understand what is going on. You can't just "specify" away the issue. You can to try to do all this as though you were writing an RFP for real estate office management software, but only if you're prepared to live with things being orders of magnitude more expensive to run than they need to be, and often far less reliable and certainly far less easy to use. You say the scientist doesn't need to know how a software development project works, but in the largest sense "managing a software development project" is identical to designing software. There is no clean distinction. Issues like whether to employ test driven design, what languages to use, how to architect the system, and even how to figure out what hardware is optimal for executing the architecture and indeed how to co-select the proper hardware and software architectures are all crucial to success. Again, if you're building software for a real estate office it is straightforward for the programmer to just learn what your business is and in any case high performance isn't needed. If you are trying to simulate supernova explosions and you can barely cram the magnetohydrodynamics in a piss poor 2D version of the problem onto the biggest machines in existence and would really, really like to do the problem in 3D, I don't think you can operate on this model. > For example, a scientist saying "you must use the PGI compiler" is > like the bridge building engineer saying "you must use Pennsylvania > coal in the blast furnace". What if a particular compiler is known to generate floating point code for certain kinds of inner loops that runs a factor of three faster than another? Would it be silly then? The coal you use has no effect on the resulting steel, but the compiler you use *does* alter the resulting machine code by a lot! By the way, I even argue that often it is important for the bridge builder to know a bit about how the steel is made. Why? Because he might falsely assume that certain kinds of characteristics are impossible to achieve in the materials and thus not ask for them, and the steelmaker might have no way of knowing that certain characteristics would be desired by the market and thus won't offer to sell the perfect material for the job. Perry -- Perry E. Metzger [EMAIL PROTECTED] _______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
