Re: [tlug] [OT] Specialized insects and Linux

[Curt Sampson <cjs@example.com>]

On 2015-11-17 01:48 +0900 (Tue), Benjamin Kowarsch wrote:

> Curt you are wrong.

I'm afraid not. :-)

> Nice try there suggesting I am one of those people that fall into your
> "what non-engineers think" category but I am actually a trained electrical
> and mechanical engineer. Safety always has the highest priority both in
> electrical and mechanical engineering. That is both work place safety and
> public safety in respect of the products to be delivered.

Well, I find your attitude to be very strange, then. Are you saying
that, as a trained electrical engineer, you look around at the
electrical wiring in your house and you believe that there's absolutely
nothing at all that could be done to make it safer? There's no possible
accident that could be happen where harm could be further mitigated by
installing a proper ground system (if your house is typical of most
Japanese homes) or more ground current fault interruptors (which I'm
betting you don't have on all your circuits)?

The answer to my rhetorical question is, of course, "there's plenty that
could be done to make it safer." There always is; for as long as anybody
can find money, an engineer can find something that would theoretically
increase safety.

Of course, an electrical engineer interested in the ultimate safety of a
family from electrical mishaps would probably do best by insisting that
no power sources be connected to the house. This would ensure (leaving
aside for the moment lightning storms and the like) that the family was
extremely safe on that front, though I doubt it would be much comfort to
them as they sat in the cold and the dark.

> As long as one does not compromise safety there is no reason why one can't
> reduce cost.

The question is, what is "compromising safety," precisely? It's not
having a system in which there's no way it would be possible to make it
safer; it's compromising on a set of standards for safety that provides
a reasonable cost-benefit ratio. People are happy to take risks (and
fairly grave ones, if the current automobile industry is any indication)
for the sake of convenience. If you don't believe that, just try to take
their cars away.

> However, should there be a conflict between safety and cost,
> then in the world of engineering, safety standards trump.

This is true, and I never said otherwise. I'm simply pointing out that
the safety standards themselves are a compromise, and one as often
driven by emotion as anything technical. (I've never found someone able
to satisfactorily explain to me why it's more important to prevent one
death by something related to the nuclear power industry than dozens
or even hundreds of deaths by something related to the coal power
industry.)

> In the world of software though, safety is never a concern.

This is untrue, of course. While in many areas of software there's not
much concern for safety, and in other areas safety and other concerns
are overridden by the managers of those who develop the software, there
are plenty of areas of software where safety is a massive concern.
Aerospace is just one example.

> In the world of engineering there is also liability. In the world of
> software, liability is not even in the vocabulary.

That is, in general, sadly true.

> Release early, fix later is not proper engineering.

So you're saying that if you can make a better, more reliable and more
secure product via "release early, fix it later," you should instead
choose to make a worse, less reliable and less secure product just
because you think that there's something inherently bad in in the
particular methodology used to create it?

Sorry, but, especially in software, you've got that completely wrong
(though you certainly share your misperceptions with a very large number
of people). Saying that some particular methodology is a guarantee that
you won't encounter certain problems is complete nonsense. Blindly
following methodology is a guarantee only that you'll probably get
yourself in to deep, deep trouble at some point.

There's a lot of received opinion in the software-building world that's
simply wrong, yet blindly followed, and that's a good part of the reason
so much software is so badly built today. Sad to say, there's a not
insubstantial portion of that received opinion that's modeled on what
people like electrical and mechanical engineers do, with those people
trying to import this stuff in to the software world not realizing that
they're often importing techniques for dealing with utterly different
problems.

> You are also mistaken about the impact. That website that you say
> isn't worth the effort can cause security risks that lead to hundreds
> of millions of losses.

Yes, but doing the website using the "release late, fix late"
methodology (which more often than not turns in to the "release late fix
never" methodology) also can cause security risks that lead to hundreds
of millions in losses and, in my experience, is actually more likely to
do so than a competently done release-early strategy.

To give you just a simple example, say you've got a six month release
cycle and I've got a daily release cycle. A new bug is discovered in the
OpenSSL library we both use. Can you show me any convincing evidence
that you, with all your planning, will have foreseen that bug and
corrected for it before it was discovered? (I'd be really interested
in how you can do that, if you can, as would the rest of the world.)
Or, if you intend to fix stuff like this through new releases (already
going against your "get it right the first time" strategy--maybe you
should have waited to release!), what on earth makes you think that your
team, which has done four releases in the past two years, is going to be
anywhere near as fast or effective at getting out a new, stable release
than my time, which has been doing it every day for the last two years?

> And even if there are no security issues, the willingness to incur
> technical debt in software is already costing billions of dollars.

It sure is. But the solution there is to explicitly avoid technical
debt, and avoid things (like the front-loaded processes you appear to be
proposing) that tend to push people towards accepting technical debt.

> Latest example this last week was Deutsche Post with a 385 million
> EUR write off due to technical debt in software, and on the news
> their share price fell 71%. That is what you get when your mantra is
> features, ship early, fix later.

Do you have any evidence that that's what happened? Because my
experience has been that the vast majority of situations like Deutche
Post's have actually been the fault of "do massive amounts of
speculative design and coding up front and wait a long, long time to get
it in to production where we can see if it actually works."

> And no, I didn't advocate making things perfect. You misread that.

Actually, you did say that and didn't realize that you were saying it.
If, for example, in the area of security you can't list a half dozen
ways to compromise the security of your system, you don't understand
your system well enough to be making decisions about how it should be
secured.

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch