berger@well.UUCP (Robert J. Berger) (01/08/90)
I have a situation where I have inhereted a team that is made up of programmers who call themselves software engineers. Unfortunatly they know nothing about software engineering. Worse is that they don't know they don't know anything about software engineering. Concepts of product lifecycle, design documents, schedules, testing plans, metrics, reusablity, portability, etc are alien concepts that have no place in their rush to write code. Software Quality methods and concepts are of no use to them. The words sustaining and maintenance draw blank stares. The product they have produced reflects this mentality. It is huge in terms of number of lines of code. Much larger than is needed to accomplish the task. It looks to be virtually unmaintainable as there is absolutely no formal spec, no design documents, etc. My question is, Does anyone know of a videotape or small easy to digest book or article that communicates the down side of bottom up random hacking and the up side of engineering? Something that would clearly demonstrate the win of planning, testing, software Quality orientations. I am particularly interested in examples in the embedded systems realm as opposed to the Data Processing MIS realm. How have other people dealt with transforming a team of narrow minded prima donna programmers into engineers? Is it doable? Bob Berger
jmi@devsim.mdcbbs.com (JM Ivler - MDC - Douglas Aircraft - Long Beach, CA) (01/08/90)
In article <15413@well.UUCP>, berger@well.UUCP (Robert J. Berger) writes: > > How have other people dealt with transforming a team of narrow minded > prima donna programmers into engineers? Is it doable? > Bob, The simple answer is yes. To do it you have to take the one programmer that is most interested in increasing thier productivity, and give them a small sub-task to perform. You must write a simple paragraph that explains what you want done then have them perform the task as follows: 1) write a simple paragraph that details what the program is supposed to do 2) write a simple paragraph of how the program is going to do it 3) write what the expected inputs and outputs of the individual process are 4) write, in simple english, the structure of the individual routines 5) write a plan to test the input and outputs (as expected) 6) write the code 7) perform the tests Once completed, explain the significance of the individual documents. Yours: Requirements Thiers: 1) Analysis 2) initial design 3) detailed design 4) psudo-code 5) test plan 6) program 7) testing and integration Now, take another programmer and ask them to add a function to this piece of code. Provide them with the associated documentation and tell them that they have to follow this same set of procedures. Within a day or so that progammer will see how easy it is to modify the existing code. This will start the cycle of re-educating the programmers. This cycle is *very* time consumming and intensive. There are no real shortcuts I have tried that have ever worked. This is the only method that I have used to date that will establish the desire within the programmers to change, and without that desire, there can be no change. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | J.M. Ivler at Douglas Aircraft in Long Beach, CA - VOICE: (213) 496-8727 | | INTERNET: jmi@devsim.mdcbbs.com | UUCP: uunet!mdcbbs!devsim.mdcbbs!jmi | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
reggie@dinsdale.nm.paradyne.com (George W. Leach) (01/08/90)
In article <15413@well.UUCP> berger@well.UUCP (Robert J. Berger) writes: >I have a situation where I have inhereted a team that is made up of >programmers who call themselves software engineers. Unfortunatly they >know nothing about software engineering. Worse is that they don't know >they don't know anything about software engineering. Titles can be very misleading in this industry. This still proves that the demand for skilled professionals far outstrips the supply.... >Concepts of product lifecycle, design documents, schedules, testing >plans, metrics, reusablity, portability, etc are alien concepts that >have no place in their rush to write code. Software Quality methods and >concepts are of no use to them. The words sustaining and maintenance ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >draw blank stares. ^^^^^^^^^^^^^^^^^ Ah, here is a key clue to the solution. >The product they have produced reflects this mentality. It is huge in >terms of number of lines of code. Much larger than is needed to >accomplish the task. It looks to be virtually unmaintainable as there >is absolutely no formal spec, no design documents, etc. Who has to maintain this stuff? It doesn't sound like the original group does. >My question is, Does anyone know of a videotape or small easy to digest >book or article that communicates the down side of bottom up random >hacking and the up side of engineering? Something that would clearly >demonstrate the win of planning, testing, software Quality orientations. >I am particularly interested in examples in the embedded systems realm as >opposed to the Data Processing MIS realm. No, nothing worthwhile. Take that group and put them into a maintenance role. Make sure they maintain code that is equally as bad as theirs is. But make sure it was not written by them. The original programmers are not available, there is no documentation, etc...... Give them a taste of their own medicine. It *IS* the *ONLY* way they will learn. >How have other people dealt with transforming a team of narrow minded >prima donna programmers into engineers? Is it doable? My impression is that this is quite difficult. You need people who not only have been trained as engineers, but also believe in the techniques and philosophy as well. Your problems are not so much one of lack of education (or I should say ability to learn) as they are a lack of desire to change. George George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
mjhammel@Kepler.dell.com (Michael J. Hammel) (01/10/90)
In article <514.25a87b3d@devsim.mdcbbs.com>, jmi@devsim.mdcbbs.com (JM Ivler - MDC - Douglas Aircraft - Long Beach, CA) writes: > In article <15413@well.UUCP>, berger@well.UUCP (Robert J. Berger) writes: > > How have other people dealt with transforming a team of narrow minded > > prima donna programmers into engineers? Is it doable? > > > Bob, > ... > 5) write a plan to test the input and outputs (as expected) > ... > 7) perform the tests > I might also suggest you make use of any decent software test engineers you have handy. I, as a test engineer, try to follow some formal methods in developing and executing software tests. Recently I had to test some software that had little documentation and poor design specs. I was able to show numerous flaws because I forced specifications out of the design group *after* the product had been delivered to me. It showed that they didn't know exactly what it was they were after to begin with. It also helped to show the importance of the steps that have been listed in previous posts on this subject. A good (thorough, well planned) test plan will definitely show the importance of well planned design specifications. Michael J. Hammel | internet: mjhammel@Kepler.dell.com Dell Computer Corp. | Also: ...!dell!mikeh or 73377.3467@compuserve.com Disclaimer equ standard
UH2@PSUVM.BITNET (Lee Sailer) (01/11/90)
I think you are unlikely to succeed without support from higher levels of management. It could take 12-18 months before real payoffs start to appear, and during that time your people will need to learn new ways of looking at their work, so it seems likely that their productivity might decrease. I think the other advice offered here is good, but that you shouldn't hit your head against the wall. lee
dwiggins@atsun.a-t.com (Don Dwiggins) (01/11/90)
In article <15413@well.UUCP> berger@well.UUCP (Robert J. Berger) writes:
My question is, Does anyone know of a videotape or small easy to digest
book or article that communicates the down side of bottom up random
hacking and the up side of engineering? Something that would clearly
demonstrate the win of planning, testing, software Quality orientations.
I am particularly interested in examples in the embedded systems realm as
opposed to the Data Processing MIS realm.
How have other people dealt with transforming a team of narrow minded
prima donna programmers into engineers? Is it doable?
Not without pain. They've got to learn to understand, in their guts, the
consequences of the way they do things. No "easy-to-digest" book or article
will give them this. Some of the other responses have good suggestions for
"giving them religion".
For your own use, I recommend the book "Managing the Software Process" by
Watts Humphrey (Addison-Wesley, 1989). A good overview of it is in his
article in the March 1988 issue of IEEE Software. The book relates some
horror stories that might be of some use to you, as well as laying out a
step by step plan to improve the process.
Good Luck.
--
Don Dwiggins "Solvitur Ambulando"
Ashton-Tate, Inc.
dwiggins@ashtate.a-t.com