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

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2015-11-17 01:48 +0900 (Tue), Benjamin Kowarsch wrote:
 > 
 > > Curt you are wrong.
 > 
 > I'm afraid not. :-)

+1 :-)

 > > 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.

Especially in Japan, where the "ura-manyual" has people carrying
around critical masses of fissionables in open buckets and
mathematical induction stops at 14.  Not to forget piling-testing-by-
copying-machine.  (The point is not that Japanese engineering sucks,
although that may be arguable.  It's that it's a management
decision.  See below.)

 > (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.)

And you won't.  The real issue with the nuclear power industry here is
that it's too big to stop and too dumb to not need stopping.  They
didn't learn from Chernobyl, they didn't learn from Tokaimura, and
they didn't learn from Fukushima Dai-ichi.[1]  I agree with you on the
nukes vs. coal tradeoffs in the U.S.[2], but despite Japan's vaunted
monozukuri traditions, I don't think their safety standards can
compare to having ex-nuclear-submariners standing watch in the power
stations.  Japanese nukes scare me.

 > > 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.

Uh, tell that to Toyota (Prius brakes).  I believe there have been a
couple of big payouts over medical equipment software was well (at
least one involving an actual court case).  On the other hand, genuine
torts that arise from software failures are generally rare.  For
example, you'd think that people could sue over the DoS committed by
Yahoo! in April 2014[3], but not.  Product defects where the product
fails to work as advertised are not usually torts unless a warrantee
is offered.  We'll see about privacy issues, but (in the U.S.) that
one will have to hashed out in the courts.

 > 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.

Cite?  I'd like to learn more about this.

 > 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.

Er, you can't avoid technical debt (or front-loaded processes) in
general.  The problem is that until recently, managements had no idea
how to budget for technical debt.  That meant that they didn't.  (More
precisely, they hoped it would be covered by their reserve
allocation.)  We now know a lot more about software engineering,
including cost estimation.

And it's *always* a management problem, even if you do know how to
deal with the cost estimation.  Engineers are generally not given the
whole picture, they're given a specification written by management (or
worse, marketing).  It's up to management whether to bear costs now
(which may be an issue of survival) vs. in the future (when it just
means taking an asset writedown and a hit on your stock price).

The best they can do within their job description is to implement that
specification at minimum cost.  A sufficiently smart engineer (SSE)
can recognize risks involved in a specification, and professional
ethics demand reporting those to management, relevant regulatory
agencies (whistle-blowing) and perhaps even the press.  An SSE with
time on his hands might even dig past the specification to the
requirements provided by marketing, and perhaps even talk to the
end-user.  But even after all that, his *job* is to implement
management's spec at lowest cost.  If he doesn't like that, he can
quit (or force management to fire him).

And while we're bashing management, again when it comes to offering a
warrantee versus paying a lawyer to weasel-word the disclaimer of
warrantee, the buck stops here.  Not at the engineer's workstation.

So (in case it isn't obvious), I agree with you whole-heartedly about
the engineer's role.

 > > 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?

Well, a minimum of research shows that DP wrote off EUR 308 million in
development costs and EUR 37 million in rollback costs for pilot
installations.  So at least 15% is due to botching the project, not to
technical debt.  The articles also mention cost overruns etc, so I
suspect that quite a large portion of the writeoff was actually due to
botched management of the project itself, a conclusion bolstered by
the fact the DP-DHL apparently has admitted it's not competent to do
the work itself, after all.  (BTW, it was earnings, not the share
price, that fell 71% -- a figure that is absolutely meaningless in
period where such a charge is takeuin against earnings.  The share
price fell by 2.6%.)  It's arguable that "technical debt" was
responsible for the risk involved in putting all eggs in a basket that
was slated to cost 750 million altogether, rather than "rolling
upgrades" of the kind you advocate, but I'm not sure that rolling
upgrades are really feasible in a case like this.  WDYT?


Footnotes: 
[1]  "We'll get you out somehow" is not an acceptable evacuation plan.

[2]  The computation I saw on Three Mile Island compared sitting
on the top of the containment structure throughout the incident with
living a year in Denver, and concluded you really ought to stay in
Pittsburgh if radiation worries you.

[3]  A lot of people using Yahoo! addresses for their businesses had
their emailed bills refused because the service they were using for
billing was not Yahoo!.