Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
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 |
From: Arved Sandstrom on 14 Feb 2010 11:03
Martin Gregorie wrote: > On Sun, 14 Feb 2010 14:14:26 +0000, Arved Sandstrom wrote: > [ SNIP ] >> 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. I don't exactly see it happening at the federal or provincial or municipal levels in Canada either. Not any time soon. Which is ironic, because this would simplify the lives of PMs and higher-level managers. AHS |