Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Brad Spencer <>
To: segaloco <>
Subject: [COFF] Re: [COFF from TUHS] Re: yet another C discussion (YACD) and: Rust is not C++
Date: Wed, 01 Feb 2023 08:41:59 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (message from segaloco via COFF on Wed, 01 Feb 2023 01:50:05 +0000)

segaloco via COFF <> writes:

> COFF'd


> Long story short, most people don't know how their programs work because they aren't really "their" programs so much as their assembly of a number of off-the-shelf or slightly tweaked components following the norms of whatever school of thought they may originate in (marketing, finance, graphic design, etc.).  Sadly, this decoupling likely isn't going away, and we're only bound to see the percentage of "bad" software increase over time.  That's the sort of change that over time leads to people then changing their opinions of what "bad software" is.  Look at how many people gleefully accept the landscape of smart-device "apps"....
> - Matt G.

At my last $DAYJOB the developers were more or less not allowed to alter
components that were acquired external to the company.  That is to say,
no "slightly tweaked" was permitted.  If it was in house developed, that
was another matter.  This led to more then one occasion where a problem
that could have been solved with a software fix to the product stack had
to be dealt with in infrastructure because they would not fork something
they acquired from github.  Or they ended up utilizing the
infrastructure in a very inefficient manor because they would not alter
something or other and then blamed infrastructure for having bad
behavior.  I am pretty sure that the general understanding of what was
being developed was low with most of that group.

The development group was intentionally not writing software for the
long haul.  If something didn't work it was refactored, if possible and
if the "it" was important enough, or infrastructure was blamed and made
to work around the problem or they just forced the user community to
deal with the problems (especially if the user community was in house
coworkers).  The life cycle of much of the code was less than 3 years
and in a lot of cases was reimplemented every year (there were some
exceptions, of course...).  It may have been "bad software" but as long
as it worked for its purpose right now, that really didn't matter.

Brad Spencer - - KC8VKS -

  reply	other threads:[~2023-02-01 13:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
     [not found]           ` <>
     [not found]             ` <>
     [not found]               ` <>
     [not found]                 ` <>
2023-02-01  1:50                   ` segaloco via COFF
2023-02-01 13:41                     ` Brad Spencer [this message]
     [not found]               ` <>
2023-02-01 19:29                 ` [COFF] Re: [TUHS] Algol rules: was something about " Steffen Nurpmeso
2023-02-01 20:00                   ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).