From: LR on
James Kanze wrote:
> On Feb 11, 9:33 pm, Andy Champ <no....(a)nospam.invalid> wrote:
>> Lew wrote:
>>> Andy Champ wrote:
>>>> In 1982 the manager may well have been right to stop them
>>>> wasting their time fixing a problem that wasn't going to be
>>>> a problem for another 18 years or so. The software was
>>>> probably out of use long before that.
>>> Sure, that's why so many programs had to be re-written in 1999.
>>> Where do you get your conclusions?
>> Pretty well everything I saw back in 1982 was out of use by
>> 1999. How much software do you know that made the transition?
>> Let's see.. Operating systems. The PC world was... umm.. CP/M
>> 80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers
>> for Windows 2000. That's at least two, maybe three depending
>> how you count it, ground-up re-writes of the OS.
>> With that almost all the PC apps had gone from 8 bit versions
>> in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with
>> non-preemptive multitasking and finally to a 32-bit app with
>> multi-threading and pre-emptive multitasking running in
>> hundreds of megs.
>> OK, so how about embedded stuff? That dot-matrix printer
>> became a laserjet. The terminal concentrator lost its RS232
>> ports, gained a proprietary LAN, then lost that and got
>> ethernet. And finally evaporated in a cloud of client-server
>> computing smoke.
> 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?

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.

Not all locomotives last 40 years.

Design flaws can contribute to a shorter life. For example the Erie Triplex.

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.

>> 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: ;)
) 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.

I think ultimately the RRs asked themselves if they were in the
locomotive business or the transportation business.


From: Seebs on
On 2010-02-13, Leif Roar Moldskred <leifm(a)> wrote:
> Why? We're not today, and the gears of the open source engine appears fairly
> well greased regardless.

In practice we are -- you can give stuff away labeled "WITHOUT ANY WARRANTY"
and no one seems to feel this is a problem.

The proposal that we should legislate that software CANNOT be distributed
without warranty would be destructive.

Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a) <-- lawsuits, religion, and funny pictures <-- get educated!
From: Lew on
Arved Sandstrom wrote:
> Let's take it as a given that free software has a decent model. I've
> been, and still am, a participant in the process of creating free
> software, and I wouldn't do that if it wasn't a good model. However, the
> main problem with it is that it engages only a small fraction of all
> software developers, and accounts for only a very small fraction of all
> software that is written.

Only a small fraction of software developers (and I've known for a long time
you were in that group) are good enough to write good software, free or otherwise.

Most of us do need to get paid, and few of us can make more money than as
software developers or related jobs. That gives those who are good developers
little time to spare for writing free software.

> But the real problem, which is not addressed by free software, and which
> comprises the huge majority of all software, is custom stuff. And it is
> this category that suffers, and suffers badly, from the lack of
> professionalism in our field. It is this category where clients would
> benefit from having proven, guaranteed quantities when it comes to
> employees/contractors and products.

There should be a much wider gap between the pay scale of the good developer
and that of the putz or newbie. Something akin to the gap between top actors
and those who have to wait tables, or top pro athletes and those in the minor

From: Arved Sandstrom on
Jerry Coffin wrote:
> In article <hku5go$af0$1(a)>,
> John.koy(a) says...
> [ ... ]
>> Exactly. Engineering is about measurable outcomes, quantification.
>> What's the equivalent of "this building can withstand a quake of
>> magnitude 7.5 for 30 seconds" in software? Can any of us state "this
>> software will stand all virus attacks for 12 months" or "this software
>> will not crash for 2 years, and if it does your loss won't exceed 20% of
>> all digital assets managed by it" ?
> Your analogy is fatally flawed, in quite a number of ways.
> First of all, a particular piece of software is only one component in
> a much larger system of both hardware and software -- where the final
> system is generally designed and assembled by a somebody who's not an
> engineer at all. What you're asking for isn't like a warranty on a
> building. It's more like asking a vendor of steel beams to warrant
> that any possible building of any design will withstand earthquake X
> as long as it includes this particular component.
[ SNIP ]

And to continue the analogy, what would be reasonable to ask for is that
the steel beam vendor warrant his steel beams provided that they are
properly used according to his specifications. We can actually do that
for software components as well.

From: Mike Schilling on
Lew wrote:
> There should be a much wider gap between the pay scale of the good
> developer and that of the putz or newbie.

I do not think that words means what you think it means.