Languages, is popularity dominating engineering?

On Mon, 22 Dec 2014 09:51:22 -0800 (PST), Ed Prochak
<edprochak@gmail.com> wrote:

>On Saturday, December 13, 2014 4:43:51 PM UTC-5, upsid...@downunder.com wrote:
>[]
>> 
>> One should consider the expected lifetime of the software. If the
>> software expected life time is one or more decades, one must think
>> about the amount of competent programmers available at the end of that
>> period.
>> 
>> Using some exotic languages or something gaining rapidly popularity
>> recently (and possibly falling off as quickly) would be a risk. Using
>> some main stream languages (such as C/C++) and there will still be
>> competent programmers for a few decades.
>
>Some businesses I've seen do not consider that problem. Management can
> be VERY short sighted.
>
>From the Engineering side, I think that where available special languages
> are appropriate. A simple example is SQL.
>> 
>> I haven't done COBOL since the Y2K issues, but still encounter Fortran
>> applications written two decades ago and the users wondering what to
>> do during the next decade and when to rewrite it,
>
>Well, it depends. Are the requirements and designs well documented?
>
>FORTRAN is a functional language and should be fairly easy for a
>good programmer to learn. I'd rather hire a programmer that still
>wants to learn new things than one that picked up a set of languages
>in school and will not look outside that toolbox.
>
>Lastly are the build tools still available (compiler/linker)?
>Is the OS still available?
>
>This actually is a fairly simple Engineering style decision,
>Weigh the trade offs given the facts for the specific case.

Fortunately, this is not a problem today, but after 10 years ...

Even if you hire some person willing to learn COBOL/FORTRAN, for how
many years do you expect him/her to stay employed ?

A few years ago there was a company seeking PDP-11 assembler competent
person to maintain and train new persons for their spent fuel rod
basin until 2050. I considered applying, but unfortunately it was on
the wrong side of the Pond :-(

>>                                                  thus the existing
>> code base needs maintenance during the next 0-10 years. If those
>> applications had been written with some exotic languages or using some
>> special vendor specific extensions, maintenance becomes harder by each
>> year.
>
>I think maintenance becomes harder over time for any system.
>Bug fixes and new features are added until the code collapses if some
>forward planning is not done.
>
>Again it comes to the type of person you hire to maintain the code.
>If he/she is willing to learn, it may be easier. 

Of course, you can hire a competent person to do a single
COBOL/FORTRAN fix, but how do you expect to keep that person employed,
unless you have some more demanding day to day tasks ?

Don Y <this@is.not.me.com> wrote:

(snip)

> As "engineers", we were isolated from Marketing.  A potential
> "rationalization" for this sort of thinking was the period:  late
> 70's.  Processors were *just* seeing use in commercial/consumer
> products.  

(snip)

> I find it difficult to get "customers" (Marketing, clients, etc.) to focus
> on what they *want*, let alone *why* they want it.  They tend to know
> what they *don't* want -- AFTER they see it!  But, are largely incapable
> of abstract thought:  "Imagine this device reified before you; how does
> it work?"

I hear from real estate agents that it is the same for house buyers.
For one, it was our real estate agent explaining that we would 
imagine what it would look like, but most can't.  Sellers are supposed
to make the house look ready to move in, and especially remove junk
and excess furnishings. The house we got had lots of junk (it took the
sellers two days to move out), had been on the market for six months,
and we got it below asking price (18 years ago).
 
(snip)

> I suspect this is one of the reasons why engineers are responsible for
> so many (clumsy) designs -- "You've got to be an Engineer to use this
> damn thing!"

-- glen

Op 22-Dec-14 18:15, Don Y schreef:

> I find it difficult to get "customers" (Marketing, clients, etc.) to focus
> on what they *want*, let alone *why* they want it.

Too familiar... I always try to figure out the rationale behind a 
requirement. The "why" is usually more valuable information than the 
"what" because the "why" tends to be less likely to change and just the 
"what" without understanding the "why" rarely provides enough 
information to make a sensible implementation of what is being asked.

Asking the "why" question doesn't make one always popular though. I've 
had dealings with a customer who got rather annoyed when I asked why 
they wanted a feature (what is the benefit for you or your customers? 
how are they gonna use it?). That feature had a rather fundamental 
impact on their system and implied 10+ man-years of development so I 
would expect at least some rationale. However that customer insisted 
that I stopped asking why. Later I found out that that feature was a 
"sensitive" subject within the company and that they really didn't have 
a rationale, other than that the new management insisted on it because 
their competitor had it so they should have it too. That feature made 
sense on their competitors system as addressed a fundamental drawback of 
their system concept. However system concept of my customer did not have 
that weakness so the feature had no real added value; one could argue 
that it made the system worse. When the project was well beyond halfway 
marketing requested to have a version of the system without that feature 
because (surprise!) there was no demand for it.

I have also had a case where it was easy to point out that there was no
business case for a (in my option questionable) feature that would take
at least 4 man-months to implement:
- Could you sell the machine for a higher price? No.
- Could you sell more machines? No.
- Could you sell your machine to other customers or markets? No.
- Is there any other strategic benefit? No.
- Does it make the machine cheaper to manufacture/service..etc? No.
- How many of your customers would benefit from that feature? We know of 
only one case, we don't expect there are other cases where this feature 
would be useful.
- Would that customer pay for that feature? No.
- Would it help to get repeat orders from that customer? No, the 
decision makers there won't care about this feature.
- How often would that customer use that feature? 1 or 2 times a year at 
most.
- How much time would that feature save that customer? 5 to 10 minutes 
at most. A year? Yes, 5 to 10 minutes a year.

So the conclusion was there was no business case but we should add this 
feature anyway at the expense of features of which the added business 
value was clear. I guess I should have gotten a MBA or something 
(politics?) to understand the reasoning.

> They tend to know what they *don't* want -- AFTER they see it!

One of my customers acknowledged that, he literally said: make something 
I don't want, after seeing that I can tell you what I really want. At 
least both sides knew what to expect in this case.

> This seemed relatively consistent in my experiences in different
> application domains/market segments.  E.g., medical devices, process
> control, navigation, consumer goods, etc.  Anything that had to
> interact with people in some manner (people being "variables")
> caused this "fuzziness" in requirements.

As a contractor I work for various customers in several domains. It is 
often a hassle to get clear unambiguous requirements _and_ their 
rationale on the table. It is easiest with people who have been in their 
business for a decade or more who know their domain, know their 
customers and understand their needs, know every their product(s) and 
know their competitors and last-but-not-least have a vision where they 
want to go. However those are rare; far too often I'm sitting with 
someone at the table who has been been there for just a year or so and 
barely knows more about their market/domain than one can figure out in a 
couple of hours. Lack of vision and knowledge combined with uncertainty 
leads to "fuzziness" and the refusal to prioritize and to make tough 
choices.

Op 22-Dec-14 19:47, Don Y schreef:
> Hi Dimiter,
>
>> I am quite sure even someone totally unfamiliar with VPA would
>> find it easier to read and understand what I have written than
>> a poorly commented C source where C might be his native language
>> (and practically all of the C sources I have seen are poorly commented).
>
> But how much of your claim is based on *your* level/style of
> commentary?
>
> I've seen "heavily commented" pieces of code where the comments were
> incorrect (almost WORSE than having none at all) or inadequate (e.g.,
> "add one", "divide by time", etc.).  And, cases where there were exactly
> *zero* comments!

In my book no comments are better than incorrect comments or comments 
that really add nothing (like the examples above) because they mislead 
resp. distract. I prefer clear code with few or no comments over heavily 
commented messy code. One of the coding guidelines I wrote had a rule: 
"Don't add comments that have no added value". That was for an 
organization where the rule used to be to always add comments, resulting 
in 99% of the comments in the code being just noise.

The problem with comments is that they often are (or become over time) 
inaccurate. I do write comments to describe the interface; what does the 
function do (_not_ how), the pre- and postconditions, acceptable 
parameter values, how errors are communicated and the semantics of the 
return value so one doesn't have to look at the implementation. When 
some non-obvious implementation choices are made I describe the 
rationale. When many comments are needed to make clear what the code is 
doing, it might be time for some refactoring.

How many comments are needed also depends on the programming language; 
with low-level programming languages like assembler and C I feel more 
often the need to add some the high level perspective in the comments.

Hi Don,

On 22.12.2014 г. 20:47, Don Y wrote:
> ....
>> I am quite sure even someone totally unfamiliar with VPA would
>> find it easier to read and understand what I have written than
>> a poorly commented C source where C might be his native language
>> (and practically all of the C sources I have seen are poorly commented).
>
> But how much of your claim is based on *your* level/style of
> commentary?

Oh all of it, practically. I make choices regarding my own efficiency
based on what I can do, obviously.

>
> I've seen "heavily commented" pieces of code where the comments were
> incorrect (almost WORSE than having none at all) or inadequate (e.g.,
> "add one", "divide by time", etc.).  And, cases where there were exactly
> *zero* comments!

I have yet to encounter someone who can't write decent comments to his
sources to author something of real value so the language choice here
is irrelevant. Of course C would come to some rescue to such a person,
non-commented C sources are easier to read than non-commented VPA would
be I suppose (never saw any of these :D ), in a way crutches are useful
to someone with broken legs.

> ...
> It also gives rise to lots of ambiguity!

It _allows_ ambiguity, it is up to the author to put things in an
unambiguous way. Of course "most people" can't author text of any
significant value. Most people are better off if they have just
boxes to tick to express what they want.

>> Getting into the subtleties of how to use the tool chain is another
>> task and it takes more or less the same effort anyway, whichever tool.
>> Getting familiar with the programming language itself (i.e. the
>> non-comment part) will be necessary only if someone wants to write
>> some new code in that language; making some changes etc. to something
>> existing does not require getting really good at the language. Then the
>> simpler it is - i.e. the lower the level - the easier it will be to
>> grasp what and how to do.
>
> I don't agree.  Often there are subtleties in a language that have a
> pronounced effect on how code works.

Well yes, of course. I mean that the lower the level the less a novice
to the language has to learn - but this applies only to the lowest
level (i.e. machine code) so I agree with you, there are always
subtleties to work on - either in the language syntax or in the code
itself (making calls, passing arguments etc. etc.). So having the
lowest level available is not much help to a novice as I said earlier,
I think I was wrong about that - but it is not an obstacle either.

> ...
>>>  And, to do so in a way that allows *others*
>>> to readily understand what they are trying to say.
>>
>> Understand - yes, rewrite it - no, why would this be needed. If the code
>> they read is too old or has to be rewritten for some other reason there
>> is no binding to any language, they can write it in whatever they opt
>> for then.
>> I have had to rewrite (or wanted to rewrite) very little of my few tens
>> of megabytes of source I have written over the past 20 years.
>
> But *you* are the sole developer and have control over the product
> in its entirety.  What happens when you opt to bring someone on-board
> to assist?  Or, when you are no longer capable (interested?) in
> maintaining existing/new products?

Well neither of these has happened over the past 20 years so it would
have been a terrible choice had I opted to follow into other people's
steps and practically prevented myself from doing 90+% of what I have
done during these 20 years just because one day I might need help.
The company would not have survived to that day; it manages to live
only because I have things on offer my competitors do not have.
Put me on more level terms with them and I'll stand no chance.

>> But choosing a high level language only because one hopes it will
>> survive the next 2-3 decades so someone would find it easier to
>> make some minor modifications is just silly (and done all the time),
>> why would I restrain myself now and do 1/10th or less of what I can
>> do in my lifetime only trying to save a few days work for someone
>> a few decades later.
>
> Because other people (organizations) have other interests above and
> beyond those of an individual!

Well my interests do not extend much beyond my own work. If someone
would buy my operations (not that I am selling, this is my life and I
am 59, not out of plans for future work)it would take may be a year
of someones life to get into my work and continue it - which would
be about the same whichever the language, most of the work will go
into getting familiar with the entire "building". Definitely a bargain
taking into account that I know people who have spent at least tens
of millions for 20+ years trying to do only part of what I have
done - to no result.

>> Well yes, though I am not sure how much value this will add to the
>> plain method of just putting some links/paths as text in the source.
>
> How do you express those links?  URN's?  What if the resource isn't
> accessible at the time?

I just make it up as I go, usually it is a reference to some other file
on my disk, just some file name etc. I have had little trouble locating
what I need in seconds when I had to dig into stuff I have written
20+ years ago which means other people would find it as easy, too.

> Would you be willing to move your commentary into another document?

Not really, no. The comments are an integral part of the code, there
are comments on practically every line. Typically when I go back I
read the comments and look to the left only when I reach the point
of interest.

> The beauty of having everything integrated into a single document is
> that it's *with* the sources.  Just as you scroll up to re-read a
> description of the block of code you are examining, you could look
> up and see an illustration of the data structure that the code is
> manipulating.  Or, examine a graph of the role of a particular
> parameter in a particular algorithm.

Well of course, who would not like that. I was just saying that I would
not put much effort in that because if I had it it would not save me
that much time, I rarely have to go far back to such depth
(and my memory is good when it comes to what I currently work on).
Then may be I am underestimating it, I don't know.

> Unfortunately, the wide range of media formats that could potentially
> contain information worth preserving makes damn near every "container"
> impractical.  So far, the best compromise is PDF's as containers
> (hoping they continue to evolve to support even more objects!) with
> the code as "attachments".

Well pdf-ing the sources.... I don't think I would accept this.
If you suggest html-ing them I might begin to scratch my head but
I don't think I'll find time for that in my expected lifetime :D .

>
> As you're closer to the holiday (geographically), best wishes to
> you and L!  Keep warm (together??  ;-)

Same to you and C!

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Dimiter_Popoff schreef op 23-Dec-14 om 2:05 PM:
>
> I have yet to encounter someone who can't write decent comments to his
> sources to author something of real value

Seriously??

You mean you never have seen a comment that just distracts from the code 
itself??

OK, I agree with you if you include the negative value of a comment that 
lags a few versions behind the actual code as 'real value'....


Wouter

On 23.12.2014 г. 17:49, Wouter van Ooijen wrote:
> Dimiter_Popoff schreef op 23-Dec-14 om 2:05 PM:
>>
>> I have yet to encounter someone who can't write decent comments to his
>> sources to author something of real value
>
> Seriously??
>
> You mean you never have seen a comment that just distracts from the code
> itself??
>
> OK, I agree with you if you include the negative value of a comment that
> lags a few versions behind the actual code as 'real value'....
>
>
> Wouter


Of course I have seen. Which of my points do you actually disagree with?

Dimiter

Dimiter_Popoff schreef op 23-Dec-14 om 5:07 PM:
> On 23.12.2014 г. 17:49, Wouter van Ooijen wrote:
>> Dimiter_Popoff schreef op 23-Dec-14 om 2:05 PM:
>>>
>>> I have yet to encounter someone who can't write decent comments to his
>>> sources to author something of real value
>>
>> Seriously??
>>
>> You mean you never have seen a comment that just distracts from the code
>> itself??
>>
>> OK, I agree with you if you include the negative value of a comment that
>> lags a few versions behind the actual code as 'real value'....
>>
>>
>> Wouter
>
>
> Of course I have seen. Which of my points do you actually disagree with?

"I have yet to encounter someone who can't write decent comments to his 
sources to author something of real value"

Maybe I misinterpreted you, but have I seen plenty of people who 
(according their commenst) can't write a decent comment.

W

On 12/23/2014 4:33 AM, Dombo wrote:
> Op 22-Dec-14 18:15, Don Y schreef:
>
>> I find it difficult to get "customers" (Marketing, clients, etc.) to focus
>> on what they *want*, let alone *why* they want it.
>
> Too familiar... I always try to figure out the rationale behind a requirement.
> The "why" is usually more valuable information than the "what" because the
> "why" tends to be less likely to change and just the "what" without
> understanding the "why" rarely provides enough information to make a sensible
> implementation of what is being asked.
>
> Asking the "why" question doesn't make one always popular though. I've had
> dealings with a customer who got rather annoyed when I asked why they wanted a
> feature (what is the benefit for you or your customers? how are they gonna use

Yup.  Ask of an *employer* and you're an obstructionist, "not a team player",
etc.  Ask of a client and they feel intimidated -- esp if they can't come up
with a ready reason (if there *is* one, they can take it as an opportunity
to educate them about their market)

> it?). That feature had a rather fundamental impact on their system and implied
> 10+ man-years of development so I would expect at least some rationale. However
> that customer insisted that I stopped asking why. Later I found out that that
> feature was a "sensitive" subject within the company and that they really
> didn't have a rationale, other than that the new management insisted on it
> because their competitor had it so they should have it too. That feature made
> sense on their competitors system as addressed a fundamental drawback of their
> system concept. However system concept of my customer did not have that
> weakness so the feature had no real added value; one could argue that it made
> the system worse. When the project was well beyond halfway marketing requested
> to have a version of the system without that feature because (surprise!) there
> was no demand for it.
>
> I have also had a case where it was easy to point out that there was no
> business case for a (in my option questionable) feature that would take
> at least 4 man-months to implement:
> - Could you sell the machine for a higher price? No.
> - Could you sell more machines? No.
> - Could you sell your machine to other customers or markets? No.
> - Is there any other strategic benefit? No.
> - Does it make the machine cheaper to manufacture/service..etc? No.
> - How many of your customers would benefit from that feature? We know of only
> one case, we don't expect there are other cases where this feature would be
> useful.
> - Would that customer pay for that feature? No.
> - Would it help to get repeat orders from that customer? No, the decision
> makers there won't care about this feature.
> - How often would that customer use that feature? 1 or 2 times a year at most.
> - How much time would that feature save that customer? 5 to 10 minutes at most.
> A year? Yes, 5 to 10 minutes a year.
>
> So the conclusion was there was no business case but we should add this feature
> anyway at the expense of features of which the added business value was clear.
> I guess I should have gotten a MBA or something (politics?) to understand the
> reasoning.

Marketing types tend to see "having more" as better than "having less".  They
don't see the consequences of this (reliability, development time, cost,
extra complexity reflected to the user, etc.) but know that they NEVER want
to hear themselves utter the dreaded words, "No, ours doesn't DO that".

(Heck, many software products have salesfolk who outright *lie* about what
their product is "capable of doing"... their rationale is probably something
along the lines of "Well, if we rewrite major portions of the software, I'm
sure it *could* do those things so I'll just say it DOES them, currently!")

>> They tend to know what they *don't* want -- AFTER they see it!
>
> One of my customers acknowledged that, he literally said: make something I
> don't want, after seeing that I can tell you what I really want. At least both
> sides knew what to expect in this case.

If you're being paid T&M *and* don't mind "burning time" on something that is
likely to be discarded, that can work.  OTOH, client can later conveniently
forget all this and start complaining about "how long it's taking" or "how
much it is costing", etc.  People have selective memories  :>

Personally, I don't like "wasting hours" on something just because someone
couldn't (or didn't *want* to!) sit down and figure those things out
beforehand.  I treat hours as "pieces of my life" -- irreplaceable!

>> This seemed relatively consistent in my experiences in different
>> application domains/market segments.  E.g., medical devices, process
>> control, navigation, consumer goods, etc.  Anything that had to
>> interact with people in some manner (people being "variables")
>> caused this "fuzziness" in requirements.
>
> As a contractor I work for various customers in several domains. It is often a
> hassle to get clear unambiguous requirements _and_ their rationale on the
> table. It is easiest with people who have been in their business for a decade
> or more who know their domain, know their customers and understand their needs,
> know every their product(s) and know their competitors and last-but-not-least
> have a vision where they want to go. However those are rare; far too often I'm
> sitting with someone at the table who has been been there for just a year or so
> and barely knows more about their market/domain than one can figure out in a
> couple of hours. Lack of vision and knowledge combined with uncertainty leads
> to "fuzziness" and the refusal to prioritize and to make tough choices.

Keep in mind that there are often people above the ones you are dealing
with.  And, the guy *you* are dealing with probably doesn't want to bring
"reality" ("bad news") to *his* boss, either.  So, he's willing to gamble
that it will magically be easier (cheaper, faster) than you are suggesting
at the outset.  Or, that the project might get canceled for OTHER reasons
before The Truth manifests.

I had an employer who was visibly upset with me for finding a bug in
a piece of custom silicon (it wasn't *my* design).  *I* looked at it
as saving them an iteration at the foundry (I found the bug before
the silicon was produced).  *He* apparently looked at it as "Crap!
Now I have to tell *my* boss we'll be late..."  (Um, would you rather
tell him you're going to be EVEN LATER after you have the defective
silicon in your hand?  And, the invoice waiting to be paid for that
iteration??)

(sigh)

On 23.12.2014 г. 20:01, Wouter van Ooijen wrote:
> Dimiter_Popoff schreef op 23-Dec-14 om 5:07 PM:
>> On 23.12.2014 г. 17:49, Wouter van Ooijen wrote:
>>> Dimiter_Popoff schreef op 23-Dec-14 om 2:05 PM:
>>>>
>>>> I have yet to encounter someone who can't write decent comments to his
>>>> sources to author something of real value
>>>
>>> Seriously??
>>>
>>> You mean you never have seen a comment that just distracts from the code
>>> itself??
>>>
>>> OK, I agree with you if you include the negative value of a comment that
>>> lags a few versions behind the actual code as 'real value'....
>>>
>>>
>>> Wouter
>>
>>
>> Of course I have seen. Which of my points do you actually disagree with?
>
> "I have yet to encounter someone who can't write decent comments to his
> sources to author something of real value"
>
> Maybe I misinterpreted you, but have I seen plenty of people who
> (according their commenst) can't write a decent comment.
>
> W
>

You did not misinterpret me, I also have seen plenty such people.
The ambiguity is in how we define "real value", which of course
can differ not only from person to person but within the values
of a single person depending on his current needs, mood etc. :-).

Dimiter