cox@stpstn.UUCP (Brad Cox) (07/14/90)
In article <JWG1.90Jul11165032@bunny.gte.com> jwg1@gte.com (James W. Gish) writes: >In article <112896@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: >Subroutines and parameters or even objects and methods >as we know them today just DON'T cut it; they are just not easily >composable. We desperately need some new ideas here. > Wouldn't bringing some very old and well-proven ideas thoroughly online do too? Check out Paul Morrison's work (IBM Toronto), Fabrik (Ingals et al; second OOPSLA Proceedings), LabView (commercial laboratory automation product; National Instruments), Metaphor (commercial product; Metaphor computer systems). For that matter, check out Unix shell programs. All support dataflows; a *wonderfully* composable kind of "object" if you can avoid getting people too hung up on the fact that dataflow objects don't support inheritance. The repertoire only begins, not ends, with lightweight and heavyweight dataflows (processes). There are also Linda objects, constraint-based objects, etc, etc. There is no shortage of technology. What we're lacking is the determination to use technologies already rotting on the shelves. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
bwb@sei.cmu.edu (Bruce Benson) (07/17/90)
In article <5361@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: <much deleted> >There is no shortage of technology. What we're lacking is the determination >to use technologies already rotting on the shelves. How does the average software organization introduce or import new technology? How do they track and understand it to know that it will work in their environemnt? How many orgnaizations really understand how software gets built in their own organizations (ask a middle manager, then ask the practitioners - thou tough to always get honest answers)? <grunt.climbing.groan.up.oof.on.ouch.soap.box! ;-)> We don't lack determination as much as we seem to lack the understanding of how to adopt and institutionalize the technology. There seems to be a few enduring fundamentals: 1. You must understand how things REALLY get done before you can improve on productivity and quality (or just solve development problems). Ask the people doing the work - those most affected by new technology being considered. 2. Learning a new technology (method, software, process, etc.) takes time and temporarily reduces productivity and quality. If your priority is to deliver that product in the minimum time, you may not REALLY be interested in changing to a better way of doing software. 3. It takes time for a new technology to be used productively throughout an organization. Hughes Co did a study that showed it took them about six years (plus or minus two) to institutionalize a new software technology (if it was used at all). 4. PEOPLE are the active element in software. Technology is worthless without people using it, especially where technology is used to enhance the creative work of people. New technology should be viewed in terms of how it effects the individual practitioner not the inherent power in the technology. Useability, technology maturity, education, support, etc., become the first considerations, not the last. People have done wonderful work with all sorts of obsolete technology. I suspect they can even do better ... just ask them how you can help. <Wuummmppp! off of soap box :-)> * Bruce Benson + Internet - bwb@sei.cmu.edu + + * Software Engineering Institute + Compuserv - 76226,3407 + >--|> * Carnegie Mellon University + Voice - 412 268 8496 + + * Pittsburgh PA 15213-3890 + + US Air Force
mcgregor@hemlock.Atherton.COM (Scott McGregor) (07/18/90)
In article <7881@fy.sei.cmu.edu>, bwb@sei.cmu.edu (Bruce Benson) writes: > How does the average software organization introduce or import new > technology? > ... > 4. PEOPLE are the active element in software. Technology is worthless > without people using it, especially where technology is used to > enhance the creative work of people. New technology should be viewed > in terms of how it effects the individual practitioner not the inherent > power in the technology. Useability, technology maturity, education, > support, etc., become the first considerations, not the last. I have found that whenever new technologies are to be introduced, it is critical to identify the "change agents". Change Agents must be the first to find out about the new technologies. These people have a high tolerance for things changing out from under them. They take high pride in their ability to "tame" new technology. Most other people can't deal with so much shifting technology, in their eyes such new technology discover interferes with their personal productivity because they see themselves focussing on the new technology and not the task. In order to avoid this lack of personal productivity people don't adopt the new technologies quickly. Instead, they wait until they notice that their nearby change agent is using the technology. Then they will adopt it, thinking that if they have any problems that they will talk with their local change agent (key point--they consult a local person, not read the manual!). Failure to train the change agents first causes two problems. First, people will come to them and they won't be able to help, and that will slow down adoption. Second, in many cases they will resist the new technology because they enjoy the guru role and that role has been usurped by others. They will bad mouth the product and eventually everyone will decide that the new technology was misguided because the change agent's judgement slowly ebbs into all the people who would consult them. Real change agents are sometimes actually considered troublesome because they have so much profound "uncontrolled" effects on the people around them they introduce many technologies that management didn't plan as well. Unfortunately, you cannot create a change agent. You can't appoint someone the role. Some people play the role naturally in any organization and you have to find them out. When you attempt to introduce change through an appointed change agent team, rather than the existing change agent team, you exacerbate the problem of resistance mentioned above. You are undercutting someone's personal source of self-worth, and they fight you. Many manager don't like this. It means that instead of "simple" and "logical" structures for introduction of new technology they must deal with irrational ad hoc ones based on personalities. There is less apparent control in dealing with the existing change agents. However, the control of appointees is only apparent since the hard to detect and correct undermining behavior is usually not correctly forecasted and prepared for. In the end, you play by the real change agents rules whether you planned to or not Scott McGregor mcgregor@atherton.com