johnb@srchtec.UUCP (John Baldwin) (09/19/90)
In article <614@janus.Quotron.com> cws@janus.Quotron.com (Craig W. Shaver) writes: >In article <1990Sep13.152836.24228@tc.fluke.COM>, kelpie@tc.fluke.COM > (Tony Garland) writes: >> Languages such as c++ are examples where this most certainly will not >> be true. Try taking a "cheap programmer" and getting something >> useful out of c++. >Since first learning c++ I have felt that it is not a good answer to the >need for delivering quality software in a timely fashion. Indeed. If you are developing a bigger and better version of some well- understood system, then it is probably better to stick to proven technology: languages, tools, methods, and design paradigms. [ack! He used the p-word! :-)] For instance, depending on the application, it might be better to work in Pascal or C, or even Fortran, Cobol, or Lisp. It takes a long time and a lot of cumulative experience before the best ways of using something new are discovered. In procedurally-oriented languages like Pascal, for example, it took a long time for the development of "structured programming" to become generally understood and accepted. In order to practice "software engineering," one must practice "engineering." This means the application of tried and proven techniques. All of the above implies that there must *also* be some projects which venture out on the edges of the bell curve: new applications, and attempts at using new languages, methods, techniques, what-have-you. These are not without risk. Eliminate this risk, however, and we can kiss goodbye the phenomenal rate of progress the computing field has enjoyed so far. > You must have very well qualified (and highly paid) programmers > to at least develop the basic tool sets. True. We should also remember that there have been strong indications (for a long time now) that the programmer who is twice as expensive as the median is also *ten times* more productive, in measurements of the amount of time and memory resources his or her programs consume. I'm sorry I don't have the references readily available; perhaps someone else will post them. If not, I'll try looking at home. To beat a dead horse deader: unless you are re-writing the umpteenth batch accounts receivable package, you need smart, qualified, experienced, and above all, talented professionals. Its best if you "grow your own," that is, to foster the continued rapid professional and personal growth of the people on your team. The view that programming talent is a purchasable commodity leads to high turnover, poor morale, and inflated cost of that talent. >If you follow the various c++ news groups >you will find the participants arguing about complex and arcane facits of >the language. Of course. I was too young to remember this personally, but the same kind of thing happened when Fortran (and compilers in general!) were new things, and programmers wrote in "autocoder" (an early assembler). You have to play around in the arcana before you really *know* how to use something new. -- John T. Baldwin | johnb%srchtec.uucp@mathcs.emory.edu Search Technology, Inc. | | "... I had an infinite loop, My opinions; not my employers'. | but it was only for a little while..."