Motivation of software professionals
in [Java Programming]
|
From: James Kanze on 14 Feb 2010 08:26 On Feb 13, 5:42 pm, Brian <c...(a)mailvault.com> wrote: > On Feb 13, 6:19 am, James Kanze <james.ka...(a)gmail.com> wrote: > > On 12 Feb, 22:37, Arved Sandstrom <dces...(a)hotmail.com> wrote: > > Logically, I think that most of the techniques necessary for > > making really high quality software would be difficult to apply > > in the context of a free development. And at least up to a > > point, they actually reduce the cost of development. [I really shouldn't have said "most" in the above. "Some" would be more appropriate, because there are a lot of techniques which can be applied to free development.] > I'm not sure what you are referring to, but one thing we > agree is important to software quality is code reviewing. > That can be done in a small company and I'm sometimes > given feedback on code in newsgroups and email. To be really effective, design and code review requires a physical meeting. Depending on the organization of the project, such physical meetings are more or less difficult. Code review is *not* just some other programmer happening to read your code by chance, and making some random comments on it. Code review involves discussion. Discussion works best face to face. (I've often wondered if you couldn't get similar results using teleconferencing and emacs's make-frame-on-display function, so that people at the remote site can edit with you. But I've never seen it even tried. And I note that where I work, we develop at two main sites, one in the US, and one in London, we make extensive use of teleconferencing, and the company still spends a fortune sending people from one site to the other, because even teleconferencing isn't as good as face to face.) > > So theoretically, the quality of commercial software should > > be considerably higher than that of free software. > > Practically, when I actually check things out... g++ is one > > of the better C++ compilers available, better than Sun CC or > > VC++, for example. > Maybe now that Sun CC and VC++ are free they'll improve. :) I doubt it. Making something free doesn't change your development process. (On the other hand, if it increases the number of users, and thus your user feedback, it may help. But I don't think any quality problems with VC++ can be attributed to a lack of users.) > I'm not sure about Sun CC, but guess that it is free with > Open Solaris. Still I'm not comfortable with g++'s foundation. > I would like to think that VC++, written mostly in C++, is at > least able to produce a draw when up against g++. There are a lot of factors which affect quality, but the basic development process is by far the most important one. And from what I've seen, I'd guess that Microsoft doesn't have a particularly good process. Note that it's a lot easier to have a good process when relatively few people are involved. Which works against Microsoft, and also to a degree against g++. And may contribute to explaining why the EDG front-end is so good (along with the fact that it's probably easier to find four exceptional people than to find 400). [...] > That may be a reason why an on line approach makes sense. > Since you haven't shipped out instances of the program, > just make sure the instances that exist on your servers > are corrected. The other way, a court in a distant country > might hold you liable if some customers didn't receive a > message that they should update their copy. Who knows what a court in a distant country may decide. (Note that Microsoft now uses the push model for patches---by default, automatic upgrading is activated, and you get all of the latest patches for Windows, whether you asked for them or not.) -- James Kanze
From: James Kanze on 14 Feb 2010 08:49 On Feb 13, 6:07 pm, LR <lr...(a)superlink.net> wrote: > James Kanze wrote: [...] > > The "standard" life of a railway locomotive is thirty or fourty > > years. Some of the Paris suburbain trainsets go back to the > > early 1970's, or earlier, and they're still running. > Do you happen to know if they've undergone any engineering > changes over those 40 years for safety or performance > enhancements? Engineering changes, I don't know; I think in many cases, no. (The "petit gris" commuter equipment in the Paris area certainly hasn't changed much since its introduction.) But they are maintained, with regular check-ups, replacement of worn parts, etc., and if there were a safety defect, it would be corrected. > With worn/damaged parts replacement how much of the original > equipment remains? Wheel sets, motors, controls, seats, > doors, couplers, windshields, etc. all get inspected and > replaced on schedule. Certainly. Hardware wears out. Even on your car, you'll replace the brake pads from time to time (I hope). In the case of locomotives, a lot more gets changed. But for the most part, it's a case of replacing a standard component with a new, but otherwise identical, component. Not that that was my point. My point was that any embedded software they're using was written before 1975 (more or less---in the case of the "petit gris", before 1965, when the first deliveries took place). (The "petit gris" are the Z 5300 "automotrices" used by the French railways in suburban service. They're very well known to anyone commuting in the Paris area. I'm not aware of any information about them in English, but http://fr.wikipedia.org/wiki/Z_5300 has some information in French, for those who can read French and are interested. The main point is that they were put into service starting in 1965, and are still in service, without any real changes, today.) > Not all locomotives last 40 years. > Design flaws can contribute to a shorter life. For example the > Erie > Triplex.http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/triplex/triplex.htm Certainly, and others might last longer. (But somehow, I doubt that the Erie Triplex had any embedded software, that could have failed if the locomotive had still been in use in the year 2000.) > Although design flaws played a part in the death of the Jawn Henry, I've > heard that N&W's business was undergoing changes and undercut the > companies desire to invest in coal fired power.http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/nwturbine/nflkturb.htm > >> Where do you get your conclusions that there was much software > >> out there that was worth re-writing eighteen years ahead of > >> time? > To continue with our locomotives, the replacement of coal > fired steam by diesel and electric (No, no, not this > one:http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/swisselec/swisselc.htm;)) > power was largely driven by maintenance cost, the sort that > replaces the lubricating oil, not the kind that replaces > faulty brake systems, although this played a role too. It's > nice to be able to buy parts OTS if you need them rather than > have a huge work force ready to make parts. Yes. But that's not really the issue here. I'm not sure when the Swiss started using regenerative braking on the Gotthard line, but when they did, they obviously had to retrofit a number of locomotives in order for it to work. But that doesn't mean that the original locomotives weren't designed with the idea that they'd be used 40 years; it doesn't necessarily mean that all of the programs embedded in them were replaced (although I think that a move to regenerative braking might affect most of them). -- James Kanze
From: Arved Sandstrom on 14 Feb 2010 09:14 James Kanze wrote: > On Feb 13, 2:59 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: >> James Kanze wrote: >>> On 12 Feb, 22:37, Arved Sandstrom <dces...(a)hotmail.com> wrote: > >> [ SNIP ] > >>>> I think you'd find that if there was much less free stuff >>>> available that we'd have a _different_ economic model, not >>>> necessarily a _worse_ one. > >>> There used to be a lot less free stuff available, and it was >>> worse. (It doesn't make sense to me, either, but those are >>> the facts.) > >>>> I look at warranties differently than you do. To me a >>>> warranty means that I used proper development practices, I >>>> can make informed statements that the published software is >>>> actually fit for a stated use, and that I care enough about >>>> the program to offer some support. > >>> Clearly. The problem is that most commercial firms don't do >>> that. > >> Right, and that's because usually the _only_ difference >> between free and commercial software right now is the price. >> Paid-for software doesn't come with any more guarantees or >> support than the free stuff does; in most cases you actually >> have to pay extra for support packages. > >> In effect the commercial software is also crappy because we do >> not hold it to a higher standard. I believe that a >> well-thought-out system of software certifications and hence >> guarantees/warranties will lead to a saner market where the >> quality of a product is generally reflected in its cost. > > I think you're maybe confusing cause and means. I'm not > convinced that certification of professionals is necessary; I am > convinced that some "implicit" warrenties are necessary, and > that if an editor trashes my hard disk, the vendor of the editor > should be legally responsible. > > Certification, in practice, only helps if 1) the vendor is > required to use only certified people in the development > process, 2) the certification really does verify ability in some > way, and 3) the vendor allows the certified people to do things > in the way they know is correct. In practice, I don't think 1 > and 3 are likely, and in practice, there are plenty of capable > people around today, without certification, who would do a very > good job if the vendors would ask them to do it, and structure > their organization so they can. I've worked in places where > we've produced code with quality guarantees, and where we've > produced we've produced code which met those guarantees. And > the people there weren't any more (or less) qualified than the > people I've seen elsewhere. The problem isn't the competence of > the practitioners (which is the problem certification > addresses), but the organizations in which they work. This is all true, and IMO you can only make all of that happen if we have true professionals. There is however more needed in order to tie it all together, and you've touched upon it. For certain types of work - taxpayer-funded for starters - it would not be permitted to use non-professionals. Given that, and the fact that professionals have a duty to do proper work, no PM would be able to legally go against the advice of his developers when the latter deliver it as a professional recommendation. But I agree with you, I don't think 1 or 3 are likely. Hell, I don't think 2 is likely either. >> Someone with a "glass is half-empty" perspective on this might >> bemoan the fact that the higher cost would be all about >> absorbing the cost of recalls and lawsuits and what not; I >> think the other view, that the higher cost reflects the higher >> quality, and that you will expect _fewer_ recalls and >> lawsuits, is just as valid, if not more so. > > The lawsuits are going to come. The insurance companies are > convinced of it, which is why liability insurance for a > contractor is so expensive (or contains exclusion clauses, > because the insurer doesn't know how to estimate the risk). > > -- > James Kanze
From: Martin Gregorie on 14 Feb 2010 10:02 On Sat, 13 Feb 2010 13:07:28 -0500, LR wrote: > Do you happen to know if they've undergone any engineering changes over > those 40 years for safety or performance enhancements? > Some have gone on a *lot* longer: the youngest engine on the Darjeeling Railway was built in 1925 and I remember seeing a brass plate on one saying that it was built in Glasgow in 1904. More recently, one was converted from coal to oil and fitted with a diesel generator to run the new electric water feed system and a diesel compressor for braking. Details are here: http://en.wikipedia.org/wiki/Darjeeling_Himalayan_Railway -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Martin Gregorie on 14 Feb 2010 10:18
On Sun, 14 Feb 2010 14:14:26 +0000, Arved Sandstrom wrote: > James Kanze wrote: >> On Feb 13, 2:59 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote: >>> James Kanze wrote: >>>> On 12 Feb, 22:37, Arved Sandstrom <dces...(a)hotmail.com> wrote: >> >>> [ SNIP ] >> >>>>> I think you'd find that if there was much less free stuff available >>>>> that we'd have a _different_ economic model, not necessarily a >>>>> _worse_ one. >> >>>> There used to be a lot less free stuff available, and it was worse. >>>> (It doesn't make sense to me, either, but those are the facts.) >> >>>>> I look at warranties differently than you do. To me a warranty means >>>>> that I used proper development practices, I can make informed >>>>> statements that the published software is actually fit for a stated >>>>> use, and that I care enough about the program to offer some support. >> >>>> Clearly. The problem is that most commercial firms don't do that. >> >>> Right, and that's because usually the _only_ difference between free >>> and commercial software right now is the price. Paid-for software >>> doesn't come with any more guarantees or support than the free stuff >>> does; in most cases you actually have to pay extra for support >>> packages. >> >>> In effect the commercial software is also crappy because we do not >>> hold it to a higher standard. I believe that a well-thought-out system >>> of software certifications and hence guarantees/warranties will lead >>> to a saner market where the quality of a product is generally >>> reflected in its cost. >> >> I think you're maybe confusing cause and means. I'm not convinced that >> certification of professionals is necessary; I am convinced that some >> "implicit" warrenties are necessary, and that if an editor trashes my >> hard disk, the vendor of the editor should be legally responsible. >> >> Certification, in practice, only helps if 1) the vendor is required to >> use only certified people in the development process, 2) the >> certification really does verify ability in some way, and 3) the vendor >> allows the certified people to do things in the way they know is >> correct. In practice, I don't think 1 and 3 are likely, and in >> practice, there are plenty of capable people around today, without >> certification, who would do a very good job if the vendors would ask >> them to do it, and structure their organization so they can. I've >> worked in places where we've produced code with quality guarantees, and >> where we've produced we've produced code which met those guarantees. >> And the people there weren't any more (or less) qualified than the >> people I've seen elsewhere. The problem isn't the competence of the >> practitioners (which is the problem certification addresses), but the >> organizations in which they work. > > This is all true, and IMO you can only make all of that happen if we > have true professionals. There is however more needed in order to tie it > all together, and you've touched upon it. For certain types of work - > taxpayer-funded for starters - it would not be permitted to use > non-professionals. Given that, and the fact that professionals have a > duty to do proper work, no PM would be able to legally go against the > advice of his developers when the latter deliver it as a professional > recommendation. > That would never happen in the British civil service: the higher management grades would feel threatened by such an arrangement. They'd use sabotage and play politics until the idea was scrapped. I bet the same would happen in the US Govt too. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |