cliffhanger@cup.portal.com (Cliff C Heyer) (06/29/90)
[The following by Cliff Heyer who started this collection. I say this just to help keep this collection "on thread"] Brad Cox writes... >The only historical datum I've found thus far to back this up is that >armory and congressional records showed that really *was* far more >expensive to build guns the new way. But only the producers seemed >to care; the consumers didn't really care (much) because their priority >had become easier repairability. I have to clarify my opinion here. I FULLY AGREE that OOP has advantages, and will someday yield benefits beyond what can be had today. It's just that with my work I came to the conclusion that OOP is not of immediate benefit. > I feel it is possible to >seperate the design phase from the construction phase in most instances. NO NO NO! My point is that the "construction phase" is NOT really a construction phase because you still have to DEVELOP. This is the whole problem! The term "construction" implies a production schedule, which is NOT the case. With software you are NOT assembling components, you are DEVELOPING new components and a control structure to surround them. The terms ARCHITECTURE and ENGINEERING should be substituted for"design" and "construction" respectively. > Most feel >that a program of that size[30000 lines] doesn't justify going through >the preliminaries due to the overhead. I agree. By the time the formalities are done, you can half the program finished. >Are you kidding? Every engineering firm I ever have been associated with runs >on deadlines! ...If you don't think that car manufacturers and TV makers work >under deadlines, guess again. My point is that these deadlines are by default flexible. You can't market a TV that does not work, right? Therefore the deadline gets moved whether anyone likes it or not. And I see evidence that those engineers are not pressured to the same degree as programmers. Management knows that pressure = errors = delayed completion = increased costs. (But then you have to weed out loafers who take advantage of a non-production environment to not produce.) >I don't think users of software components expect to just 'plug in' a bit >of code for instant functionality (at least, I hope not!). I'm getting sick of manager types who have never programmed (MBAs) talk about OOP this way, as if it is the "final solution" to the software problem. > I could have >done a paper design of the new phone line, but the time required compared to >the size of the project didn't justify it. You can do the same with software, >but you don't have to. It's not the only way. A great observation/explanation. You have made me aware of something I have wanted to explain to people but didn't know it. When you have a 3 man month project, it's better just to start it than spend 1 man-month spec-ing out every detail that a good programmer will do instantaneously "on the fly". >Programmers are really getting a raw deal in the >>current scenario. That's why so many of them change jobs and are >>generally disillusioned with their career. > There seems to be a belief that if >Joe Programmer says he can do it in 5 weeks, he can probably do it in 4 and >with fewer resources than he claims. ...and that they never learn from the past >so keep repeating the same mistakes over and over. They get pissed because >software groups can never come up with an accurate estimate of time and are >always over the time limits. Why don't they learn? I think managers - especially MBA types - are (expectedly) insecure about the "black magic" of programming. The only way for them to get security is to make themselves feel that they "got it done as fast as possible", and what a better way than to allocate LESS time than the programmer says he needs. Thus, by default they disrespect the programmer and treat him as if he is not telling the truth. This is the core of how programmers are getting a raw deal. They are not respected for the work they do - they are treated as if they are dishonest. (I suspect many WERE dishonest, perhaps making a manager treat all programmers that way.) They are disrespected for making estimates on DEVELOPMENT which can't be accurately quantified (you are not assembling pre-made components). >This >leads to nothing but heartburn for the programmers and engineers who are >saddled with the project. >Unfortunately, most upper management I have been exposed to couldn't care less >about the state of employees. They aren't the ones that have to do the hiring. >It's the line managers that are sucking down Rolaids and trying to figure out >how to jump through the next hoop. And they wonder about job burnout... John Dudeck writes.... >A lot of what is gained in OOD is in the de-sequentializing of our problems. Ahhh-I got you again! How does de-sequentializing happen?? Not because of the "magic" of OOP. Old command line interfaces had HUGE amounts of code to tokenize strings and then conditionals to figure out the command before executing the appropriate subroutines. All OOP has done is remove this layer, by having the user do the "IF" and "TOKENIZE" by pointing to what he wants and clicking the mouse. In other words, instead of using the computer to figure out the command we let the user tell the computer the command by pointing to it and clicking. No magic here, just the expected result of a change in hardware/ software architecture. So I agree the de-sequentializing occurs, and this is one of the exciting things to me about OOP. But I can't give OOP the credit for it. It's a result of the MOUSE. >Objects can be considered as independently executing processes. Because of >the extreme decoupling between objects, the problem is broken down into >more manageable pieces. This is also just good programming practice. You don't need to have OOP to do it, although OOP provides better facilities to implement it. >This seems to me that it should make the problem >of time estimating easier. As long as you still have to devise steps of code to solve a problem, the estimating problem is still there. ------ scotth@boulder.colorado.edu writes.... >I think this issue can be articulated in summary without taking up a few >hundred lines of text (sorry Cliff!). What's really being said here is >that the complexity of software engineering does not lie in programming >languages or in methodologies ... it lies in the *domains* we try to apply computers >to. . we apply software to many domains that aren't well understood yet >....continues...the production line vision of general computer applications is >nothing more than a dream. You don't sound like you've been outside the academic community. Outside you have to explain things in nuts and bolts to get your point across. This means you must explain what is being done wrong (classify programming as production) by comparison (assembly vs. development), and then explain what should be done (architecture/engineering). People have to understand a rational line of thinking to accept a point. You can't just proclaim something using abstract concepts and hope to be accepted. Scott McGregor writes... >> YES! I find I always have to match the estimate my manager >> suggests, because if I don't I'm in trouble. Actually this >> makes estimating easy, except that I am still responsible >> when the estimate is wrong. >Well, I can understand that. But if you also say "no guts, no glory", >what does this imply about the need for "backbone" in setting estimates >and schedules that are reasonable? I was talking about different situations. Actually I'm self-employed, and the "manager" I spoke of was a client who always made estimates for me. I gave him easy financing so he was able to repay the 4X overbudget costs over several years. But If I didn't accept his estimates, I'd have lost the work which was particularly good experience for my career at the time. > >Ah, but you can, you can pay an ASIC shop to do this for you. The difference >is that the percieved cost in starting down this path to nonstandard >solutions is high. Yes!! Here hardware engineers can be faced with the same choice as software engineers: the temptation to clean up a discrete logic board by creating an ASIC to get higher performance perhaps and encapsulation, etc. I thank Scott McGregor very much for his helpful comments. I'm sure if I had more experience in managing others (rather than only myself) I perhaps would not have the urge to blow off so much steam. Not all problems have easy answers. Also, now I say "I know I can program it, but I don't have the experience with it to estimate the needed time accurately." Experience IS key. I guess the real reason I've gone through this exercise is to develop a way of explaining to my clients "why" software can't be done on an accurate schedule, such as be explaining lack of standardized components, developing rather than assembling, etc. Previous to this I was by default a "bad estimator" because of my inability to explain the situation in laymans' terms to "non computer" types. With no defense the offense wins. Trip Martin writes.... >Actually, it was the consumer who demanded interchangeable parts for >guns. ...The government agreed and poured lots of money into achieving >that goal. I'm thinking of how AM STEREO got messed up because the government didn't come in and standardize. Now we have three or so types of AM stereo and much more complicated decoder chips in the radios to detect and decode each kind. COLOR TV's introduction was smooth because of the decision to support one format. (Actually a side issue I've wanted to discuss is after you see a TV in a big TV station, you'll wonder why they are developing HDTV. Upgrading the current system to give non-interlaced 60Hz NTSC TV studio quality at home for less than $25,000 will be all the HDTV we can use for a long time. What newsgroup would such a topic be discussed?) What if the FCC begins to regulate local area networks like they regulate the phone system, and proclaimed X-Windows to be the standard? Perhaps we could get on with life and do bigger and better things rather than waste man hours creating dozens of different GUIs? (Anyone dare to tackle this one?) Scott McGregor writes... > The problem is that people don't reuse >other people's code as easily. Sometimes it takes less time to write something yourself than to understand another program enough to predictably make use of it. Sometimes it takes a thesis to explain something you can do in a relatively short time. > Rather I >believe that the most important reasons that reuse of other people's >code fails is that it goes against some of the psychological rewards >that programmers want. You mean some programmers just have use their own code to "do it right". >The importance of human psychology on this problem is little appreciated, >but is greater than we may think. We have to look at how people get satisfaction in their work. If a programmer gets satisfaction from "using his own code" then obviously he will always resist using components. The activities by which a person gets satisfaction can directly contradict the activities needed to produce acceptable work. (eg. drug addiction an extreme example). The need for a manager who is sensitive to and can interdict destructive satisfaction-getting cannot be overstressed. The same problem can occur with managers, for example, if a manager gets satisfaction from saying humiliating things to subordinates who don't know enough to fight back. Edward Robertson writes... >What has happened is that a variety of tools, such as dBASE and Paradox, >have nice "interface builders" which, in the wrong hands, become mere >"facade builders." People see menus, multi-colored displays, and >whiz-bang functions keys and perceive an effective system, even though >there may be "nothing substantial" behind. :-):-):-):-):-) I'll second that! Tom Thomson writes... >there is no de-sequentialising at >all, programs written in OO languages would cease to work if the compiler >and/or the execution system stopped enforcing sequential semantics. >Claiming OOD provides a lot of gain in de-sequentialising our problems is >pure bunkum..... your brutal! >all of which are principles that were well understood and practised by >competent software engineers (and language designers) long before the >wonderful phrase "OO" appeared and became the flavour of the month. and before any of us would have thought of writing a book about it. We just thought that was the way you were supposed to program. Will writes... > In all the conversations so far, I've yet to see anyone mention learning > the task you are trying to program. That's all lumped into the design/architecture phase in our discussion. (I think) >I am in the end days of a fairly com > plex project, writing a "user friendly (!?)" front-end to a DMS10 > telephone switch. You know, I think there should be MUCH MORE ATTENTION to the fact that phone technology is the same as local area network (LAN) technology. People should be aware that ever since the late 60s long distance calls have been digital. Back then, it took 64KB/sec to digitize a channel, now it takes about 8KB/sec. A typical low-speed inter-office trunk is a T-1 which runs at 150KB/sec - the speed of a typical PC disk drive!! Imagine - you could have your disk drive connected over a T-1! And they did this in 1970! Note that you may NO LONGER have to send a "plumber" out to "tap" a local loop to bug a phone! Now all you have to do is install a program that stores all the digital data from a port (a phone number) and save it on the hard disk in the switch. Then the program can down load this data at 150KB/sec or 650KB/sec (T-3) or 45MB/sec on a D channel to ANY switch in the country! That is, with a switch in California you can down load this program to a switch in Maine which will "tap" the line, and then get the data the next day in California and "listen" to it. Big Brother Is Watching! (I read this in an MIT student publication). I heard this type of software is "built into" the switch to test it, but it of course can serve a dual purpose for law enforcement. A conversation takes 28MB/hour to store but can be pumped over a D channel in only 1/2 second! And digital switches are permeating small town America where some of the local loops are still on '50s open wire with glass ball insulators but are connected to the real world with T-1 digital trunks. What a range of technology!! PS WHAT newsgroup should the above phone discussion go into????? > The switch is essentially a > single purpose computer with 1.8 Megs. of executable written over a > 15 year period. An example of where OOP won't work, without starting over. Rob Kling writes... >I have yet to see a good book on the design of database systems >that is aimed at highly interactive products >(rather than at transaction-oriented >mainframe systems). > >Have you seen anything of use for professionals or students >of this kind? Nope. Maybe you should write one! It would be some amount of research to summarize what is bad and good, this type of thing is so subjective. Cliff
cliffhanger@cup.portal.com (Cliff C Heyer) (07/09/90)
This was supposed to go to Is Programming R&D or Production? Cliff