On 10/15/2015 10:40 AM, Robert Green wrote:
"Don Y" wrote in message

Aye, there's the rub. I kinda of disagree. Clients don't know the
capabilities of computers so they really can't spec out what they want
with
a true understanding of what can be done.

They don't *have* to know what the capabilities of computers or any
other technology happen to be. They can *buy* that knowledge (in the
form of a consultant).

You've just flipped the problem, not solved it. The likelihood that you or
most any other programmer is a subject matter expert in their field is not
very high. If you don't know their business intimately - as well as they
do - how can *you* determine what's best for them?

IME, they don't need expertise in "their business"/technology. Rather,
they need help in applying that to some problem or in some market.

+ I don't (need to) understand the statistical analysis that may occur
in assessing the likelihood of a particular patient contracting a
particular disease;
+ I don't (need to) understand the chemistry involved in blood assays;
+ I don't (need to) understand the marketing strategy that suggest
GIFTING the assay equipment to the customer (knowing that it will
lock them into perpetually purchasing supplies/reagents FOR that
equipment at a significant margin);
+ I don't (need to) understand FDA requirements pertaining to those
reagents, the assays to which they apply, the folks who perform
those tests or the documentation requirements thereafter;
+ I don't (need to) understand why ABC is *modified* Codabar instead
of *genuine* Codabar;
+ I don't (need to) understand why said equipment must be capable of
operating for 2 hours in the absence of power (why not 3? or 1??);
etc.

I can accept all of those items as "Given". Yet, still introduce
considerable value in:
- determining how to unobtrusively "watch" the technician's actions in
performing the assay
- how to detect the placement of a few microliters (small "drop") and
identify *where* it's been placed (and if something had been placed
there already -- contaminated sample!)
- how to do so inexpensively and robustly (e.g., so the detector isn't
compromised by ambient EMI/RFI)
- how to allow the user to introduce those ABC barcode labels on different
types of media (tubes, trays, boxes) without requiring three different
(costly) detectors
- how to protect the integrity of the data that I collect
- how to design circuitry that can operate on a given "battery mass"
for the required 2 hours
- how to encode these algorithms in a programming language that can
be maintained by others
- how to implement all of this so that it doesn't require initial
or ongoing calibration
etc.

The client can spend their time on the things that are *their*
business IP -- developing blood assays and making those repeatable
and "affordable". They needn't invest in the technology required
to *apply* that technology -- they can *rent* that expertise!

Systems analysis - make that *successful* systems analysis - is a highly
collaborative effort where the clients and their expertise meet with a
information professional well-versed with IT and what it can do. The
clients would NEVER be talking to an end programmer at the analysis stage
unless its a very small project.

Exactly. "End programmers" tend to work in cubicles and have very little
idea as to what The Bigger Picture entails. My speech synthesizer is
the sort of thing you could hand to an "end programmer" -- small (1 man
year effort) and well defined (given enough prior art and detailed
specification). What that "end programmer" needs to know can be spoon
fed to him/her in a specification. He/she has only mild interest in
the *application* ("OK, so it talks. What do *I* care WHY it's talking??")

OTOH, the system engineer needs to identify *why* this mechanism is
needed, what its role in the system will be, the limits defining its
performance, resource/development budget, the likely implementation
technology (as suggested by these other requirements), etc.

So, the "end programmer" can't just feel free to "take a PC" and "make
it talk" but, rather, is given an effective power budget: you must
be able to speak using these resources for this interval (which could
be expressed loosely as a "number of words")

By now a lot of companies big and small have learned what it means to depend
upon a lone star programmer who disappears. (See my post about WordStar.)
That often happens just because the HW moves on and the best system in the
world for Win2000 might not even load in another environment. People so
burned usually *don't* let it happen again.

Actually, you would be surprised how often this continues to occur!
I worked at a firm that based their control system on an Apple ][
computer. Long after Apple ][ computers could be *purchased*!
(tell customer that you bought the guts of the control system for
his $1M production system AT A GARAGE SALE!!)

Much of the move to dumb-down the effort required to "program"
comes from this fear of being tied to key developers. So, instead
of one or two GOOD developers, you embrace a small army of
"average" programmers.

And, find yourself missing out on key skills that are ESSENTIAL
to successful product development: e.g., system engineers!
("We'll just let one of those AVERAGE programmers take on that
role")