Several comments on this 1) Someone once said that if engineers designed buildings the way programmers design programs, one woodpecker could destroy civilization. Ignoring the false assumption that what we've go is a civilization, that is not so very far off. Chips contain engineer written micro-code -- which has bugs. Software engineers design assemblers to run on these chips -- which have bugs. Programmers code operating systems using these assemblers -- and add new levels of bugs. Higher level programmers write languages and databases -- which have bugs. The applicatons you use -- statistics packages, word proccesors, spreadsheets, browsers, e-mail packages are written on top of all of these levels of bugs -- and of course have their own bugs. 2) Another point is that actual coding is not the most difficult, nor the most time consuming part of the programming. To program something right, you damn well better know how to do it WITHOUT using a computer (even , as in some cases it would take you a few thousand years to actually to the process you know in the real world.) This means that before you design an application, you better know what kind of results the user wants, what form the input is going to take, and any intermediate information and steps required to get those results from that input. This is why the best programs are written either by lone cowboys, or by tightly knit small teams that work as equals -- without a whole lot of hiearchy. Try organizing a software development team in a classic industrial hiearchy. Person A does the "analysis". Person B does the coding. (A more recent equivalent is -- person A writes the objects. Person B specifices and assembles the objects.) Well -- since person A is the only one with the big picture he has to tell person B in pretty specific detail how to write the modules or objects. Given that modern programming languages are both terse and visual, it will probably take as long for A to tell B what is wanted as it would for A to write it herself (assuming A is competent at both code and analysis.) In practice, software teams work best when EVERBODY understands the "big picture". The work is then divided into modules, with everyone understanding where intersects others. So Sarah know that if she is going to anything that rights to file x , she had better ask Sue, and Jim know that if he touches attributes x in entity y, he'd better talk to Jane. 3) Time constraints. Generally users needs change drastically every few months or so. This means what you are trying to accomplish will change thoughout your work on the process. This has encouraged what is know as iterative software development -- where you deliberately go off half-baked to provide something immediately rather than exactly what they want in two year. You then get user feed back -- modify everything including the data structures, and actually do a try-and-fit approach to software design. Some very successful large products are done this way, using so-called Rapid Application Development tools. You can see why super-hierachal, industrial type organization does not work within a software team. This does not prevented a "lone cowboy" or roughly egalitarian team from being exploited by a hiearchal organization, or from being very exploitive towards lower level workers. Even the latter is not completely true. Somebody designing a program, who relies on management for specifications will produce a useless product. If you want good results, you need to get the knowledge which resides mostly in the skulls of ordinairy workers -- which means you damn well better have good relations with them. (BTW if the results of these good relations is that you design something which eliminates their job, this means you have been acting as a spy -- performing espionage against them. This gives computer programming something in common with social science in general. All those polls, studies learning how poor, and working people behave and what influences them -- what does that make the social scientists but spies for the ruling elites (members of this listed excepted, I assume) .) Anyway, I think you can see why computer programmers think of themselves as not being working class -- and why they are wrong. I think that while management has not given up all hope of organizing the software industry in a standard hiearchal form, they are perfectly willing to turn to all the other methods of exploitation. If you can't send the work out to cheap workers, bring the cheap workers in to do the work. Programmers aren't as priveleged as they believe. The long hours take their toll after a while. The career of the average system analyst lasts about seven years before burnout. But even the relative privilege they have is pretty well doomed. There are a lot people getting computer degrees worldwide. Some are already experiences; others will be experienced within a few years. If programmers need to have a certain degree of independence, they don't have to be paid a lot while excercising it. And once there is a large enough supply -- they won't be. > > Richardson_D wrote: > > > > > I would like to hear more about this. Programming is becoming more and more >industrialized, but business is not making a lot > of progress in harnessing this industrialization. Few big projects are finished on >time and many are abandoned. We have some > experts on the list who could comment on this. But programmers do not see >themselves as workers, from what I have seen. > > > BLS DAILY REPORT, FRIDAY, MAY 29, 1998 > > > > Organizing workers in high-technology fields like computer programming > > continues to be difficult for unions, with representation efforts > > hampered by employee attitudes and the industry's staffing structures, > > according to union and industry sources contacted by BNA.... (Daily > > Labor Report, page C-1). > > -- > Michael Perelman > Economics Department > California State University > Chico, CA 95929 > > Tel. 916-898-5321 > E-Mail [EMAIL PROTECTED]
