It is interesting to note in this discussion thread that the concentration on programming/coding cxontinue to be a powerful issue when the attention needs to be elsewhere and painfully so IMHO.
Consider the SEI's stress on "move to the left" as shown at http://www.sei.cmu.edu/director/aboutSEI.html and the whole idea of software engineering processes and the use of models and techniques such as Object Orientation and Cleanroom Software Engineering processes. The problem should be and can be solved and brought and kept under intellectual control before ever being commited to a given technology (read: code). As Fred Brooks said so well: "the hard thing about building software is deciding what one wants to say, not saying it." He also said: "The central question in how to improve the software art centers, as it always has, on people." at http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html then he further notes the need for great designers - note he did not say great programmers. Even in the olden days coding was only about 10 percent of total effort. So if the goal is better quality software, then the better psychological question to study is why programmers reject proven formal techniques and continue their brute force and awkwardness ways believing they can intellectually overcome problems of complexity. That and sweat. Formal processes are well understood in academia but not so widely practiced in industry. Why? What are the psychological factors? It's not the fear of lack of time since it is usually the case that doing things right the first time is faster/better/cheaper than a less formal approach. If you can solve that problem and get the software development community to adopt formal processes for ordinary development, you will have done a service worth billions of dollars per year. Reference http://www.computerworld.com/softwaretopics/software/story/0,10801,72390,00.html . Engineering and formal processes beat human force and intellect almost every time with a few notable exceptions yet we continue to focus on better human intellectual techniques with all its known limits (e.g. max variables one can juggle) instead of better formal techniques and the reluctance to use them. For instance most of us can do long division with decimal points via the memorized formal process we all learned in grade school but it exceeds most of the population's intellectual grasp as to why we move decimal points, borrow, etc which do allow us to solve problems beyong our ordinary intellectual capacity to solve. We are not reluctant to follow that process yet we programmers are reluctant to do all those drawings etc which have been designed to overcome our intellectual limits. My $.02. C. Wayne Hardeman William Billingsley wrote: > This might be only tangentially relevant: > > I sometimes wonder a little when "industrial relevance" comes up as an > argument for or against a teaching language ... is "industrial relevance" > desired for the sake of maintaining the students' interest, or for preparing > them for the "real world" (by which people normally mean the commercial world)? > > If it's the latter, then an argument can be made for almost any language's > "industrial relevance". Here I'm going to do the terrible thing of using > myself as an example: The commercial products I worked on for ADC (a large > multinational telco supplier) involved Java, Perl, EPM (a proprietary > language), SXP (another proprietary language!), Delphi (Borland's extension of > Object Pascal), C, C++, Javascript and SQL. I learned precisely one of those > at university (object pascal), although I used C in a number of university > projects too (without ever being taught the language). > > Even a new greenfield web project may involve all of Java, JavaScript, PHP, > Perl, SQL, and perhaps Flash. > > So to an extent, I agree with Ruven Brooks' assertion that the ability to > learn new languages is more important than a knowledge of particular ones that > are deemed "industrially relevant". > > However, it seems to me [pure opinion here] that the part of the issue lies > with recruitment -- for a programmer, picking up a new language is often > really quite easy; but HR departments tend to look for "X years Java > experience" on a CV, and recruitment agencies have been known to make an > initial sort of CVs simply by searching for the number of occurrances of the > technology they want (without reading the CVs at all at that stage). While > "industrial relevance" of teaching languages arguably might not be a factor in > a student's skills, is it a factor in the student's future employment > prospects? > > On the purist academic side, Computer Science / Computer Systems Engineering > degrees are not simply vocational courses, so that should not be a strong > consideration. On the empathy-with-student-applying-for-jobs side, I can see > how a student would find it very useful to have some popular technologies to > put on their CV. On the practical side, this then presents questions of how > the market changes with supply and demand in new technologies -- eg, in > Brisbane, it seemed [again, no empirical data, though] a lot easier to find > work in C or Delphi than Java, not because there was less demand for Java, but > because there were so many Java programmers around. > > Of course, here I've been straying well away from the question of Java's > empirical usefulness for teaching particular computer science concepts! > > cheers, > Will Billingsley > (former Senior Developer for ADC 1998-2002) > > - Automatic footer for [EMAIL PROTECTED] ---------------------------------- > To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss > To join the announcements list, mail [EMAIL PROTECTED] subscribe announce > To receive a help file, mail [EMAIL PROTECTED] help > This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ > If you have any problems or questions, please mail [EMAIL PROTECTED] - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
