Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Curt you are wrong.

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.

As long as one does not compromise safety there is no reason why one can't reduce cost. However, should there be a conflict between safety and cost, then in the world of engineering, safety standards trump. In the world of software though, safety is never a concern. In the world of engineering there is also liability. In the world of software, liability is not even in the vocabulary.

Release early, fix later is not proper engineering. 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. And even if there are no security issues, the willingness to incur technical debt in software is already costing billions of dollars. 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.

Even by your own admission, software doesn't pass, because there is no correct enough, no reliable enough and no safe enough in the vast majority of software products. The only things that matter are features, features, features.

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

On 16 November 2015 at 13:25, Curt Sampson <cjs@example.com> wrote:
On 2015-11-03 16:15 +0800 (Tue), Raymond Wan wrote:

> Maybe basic research doesn't yield immediate economic benefits.  I
> can't imagine a company paying staff to come up with mathematical
> equations, etc.

Fortunately you don't need to imagine that; you just need to look at the
companies that actually do this. E.g., RSA Security LLC.

On 2015-11-03 16:07 +0900 (Tue), Benjamin Kowarsch wrote:

> The reason may well be that proper management has a lot in common with
> proper engineering. Measure twice, cut once. Aim for correctness,
> reliability and safety.

Oh dear. That's not at all what real engineers do or are supposed to do,
though it seems to be a pretty good _expression_ of what non-engineers
(in which category I of course include software "engineers") think that
engineers do.

The primary focus of an engineer is to minimize the cost of producing
something while satisfying various other constraints related to safety,
reliability, consumer perception, and whatever else affects the sale and
marketing of your product.

Here's an example of good engineering that should particularly resonate
with computer geeks. The Apple II high-resolution frame buffer was
mapped to memory as line 0, line 64, line 128, line 1, line 65, line
129, etc. This caused programmers (particularly me when I was in my
teens :-)) some pain and anguish, and increased the overall cost of
developing software. However, it also saved a couple of resistors. The
cost savings from the latter likely outweighed the costs of the former,
and making that choice was what made Woz a great engineer.

For a more bridge-oriented example, look at all those fancy trusses with
interesting geometry and the massive calculations required to make those
work. They're not more safe than just using larger and heavier girders.
The reason engineers use them is because if you can build something
that's got the same level of safety with half the amount of steel, you
save a bunch of money.

So no, "correctness reliability and safety" are not what the engineer
aims for; they aim for "how do we do it cheaply whilst being correct
enough, reliable enough, and safe enough."

(And in case it's not clear, "safety" is very, very much
marketing-driven in many cases. Any engineer, or anybody else with half
a brain and familiar with risk management, would gladly make his next
aeroplane flight half as safe if he could double the safety of his
automobile trip to and from the airport on either end.)

> Release early, fix it later.
> Unfortunately, this attitude has now permeated into engineering.

"Release early, fix it later" is good engineering if it gets you what
you want. You don't do that when you're building Walkmans because
recalling a zillion consumer devices is hideously expensive, so it's
worth spending more on development costs with a "measure twice, cut
once" method to avoid that. But for a consumer web application, it would
be very poor engineering indeed to spend too much time trying to make
things perfect before releasing.

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

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

--
To unsubscribe from this mailing list,
please see the instructions at http://lists.tlug.jp/list.html

The TLUG mailing list is hosted by ASAHI Net, provider of mobile and
fixed broadband Internet services to individuals and corporations.
Visit ASAHI Net's English-language Web page: http://asahi-net.jp/en/


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links