Xref: utzoo comp.object:3599 comp.lang.c++:13672 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!apple!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.object,comp.lang.c++ Subject: Re: C++ and waitresses (long) Message-ID: <1991May25.222654.2046@netcom.COM> Date: 25 May 91 22:26:54 GMT References: <2325@media03.UUCP> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 52 > Sticky subject. Good programmers can produce reusable software, even in > assembler. Do we have to reduce languages down to the least skilled > programmers? Arguably, yes. If the bulk of the programmers out there aren't able to use the advanced features of a language (any language) effectively, they do not benefit from such features. One can argue about the need to educate programmers and increase the mean level of expertise, and that is all a fine and wonderful objective, but the simple fact is that it 1) may not work and 2) takes a lot of time and effort. In the meantime, what does one do for non-expert programmers NOW to make them more productive? It seems to me that if one is truly interested in affecting the overall productivity of the software industry, the best place to focus one's efforts is on helping the average to sub-average programmer, not developing increasing abstruse languages for the elite who can really make use of their features. An alternative strategy I've seen adopted at a number of sites is to admit up front that not everybody is equally talented (and that, in fact, many people truly would prefer NOT to be expected to be top-notch software designers and architects) and divide responsibilities accordingly. A project really only needs a handful of architects (in fact, too many architects get in each other's way), so why not structure things so that you only HAVE a handful of architects? Similarly, a project needs more subsystem-level technical leads and spec designers, and a large number of coders, testers, integrators, documentors, and configuration managers. Some people find this ranking and classification of people offensive, but I think that is more an artifact of the hacker mindset than anything else--certainly software seems unique among pursuits in its relentless emphasis on egalitarianism at the expense of sound management. Face it: not everyone is an architect, and it is actually rather cruel to expect them to pretend to be (and it affects the quality of the resulting design). > Chess is hard to get good at, but many have fun trying... But few achieve the level of master or grandmaster. Note how nicely this reinforces my previous comments. > I think the idea is that there are some people out there who are power > hackers. They want a language that can let them hack at a power level. > They want maximum options so they can explore new solutions... They want > maximum control... They want a lump of clay that can me molded into > anything. Indeed. There are proportionally MORE people, however, who are NOT these so-called power hackers and who are simply confused and dismayed by having so many options made available to them. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *