Prev: Unique ID in the application code
Next: Eclipse CDT vendor?
From: D Yuniskis on 10 Jul 2010 22:03
Hi Tim,

Tim Watts wrote:
> D Yuniskis <not.going.to.be(a)seen.com>
> wibbled on Saturday 10 July 2010 07:12
>
>> I just can't comprehend that. Just like not *testing* products
>> before release, etc. If you're too small to afford those
>> "luxuries", when will you have the time to go *back* and do them?
>> How will you counter the folks who claim "why should we do it for
>> *this* project? we didn't do it for the *last* project!"?
>>
>> If you can't afford to be in that business, go into some *other*.
>
> Abysmal lack of testing and lack of documentation is more common than you
> would want to imagine - especially in the UK (something to do with our world
> famous management and excellent work ethic?[1]) (irony).

No, I can *imagine* that. I just can't *comprehend* it.
I.e., it just doesn't make sense from a practical standpoint.

Bugs cost a *lot* more to fix (orders of magnitude) "post-release".

Answering email/snailmail/phone inquiries ("support") costs far more
than pro-actively answering those questions with good documentation.

And, none of this even tries to quantify the cost to reputation,
etc. in the marketplace as customers get fed-up/disgruntled with
your products (its a lot harder to *get* a customer than it is
to *keep* a customer).

The argument that "everyone is doing it" doesn't wash, either.
Here's a way to *excel* and capture greater market share and/or
command higher prices for your products. So, you'd rather
live with the market share that falls into your lap and the
prices that the *market* dictates??

> I know of places so shite that they:
>
> a) Never run a formal backup.

I suspect you will find most developers are guilty of this.
Even the ones who's livelihood *depends* on that "vulnerable data".
"Wow, I *never* expected a crash..." (um, what about an OS bug,
controller failure, computer falling onto floor, *theft*, *fire*...)

> b) Next to no documentation on anything.

But then how do they know what they are building/designing?
Or, do they just *hope* it "makes sense" (as a product) once
it is "done"? (how do they know it is "done"?)

> c) No email infrastructure despite having a domain - everyone communicates
> with customers using own personal email addresses (how very professional).

Yeah, this one always amuses me. Or a web site that is "single sheet
thin"...

> d) No version control systems of any description. Not even a policy.

I have worked with pharma, etc. suppliers who cringed when they were
held to task on these sorts of issues. I guess they expected
"Trust Us" to be a good business policy...

> [1] They only reason we had a sod-off massive Empire was because half the
> world only had pointy sticks.

.... and dull rocks.

Given how easy it is to outsource *much* of this work, nowadays,
one would think these other issues would be a great way to add-value
that was *hard(er)* to outsource. E.g., manuals written by people who
actually are conversant (not even *fluent*!) in English (gasp).
From: Paul Keinanen on 10 Jul 2010 22:42
On Sat, 10 Jul 2010 19:03:56 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:

>Tim Watts wrote:

>> Abysmal lack of testing and lack of documentation is more common than you
>> would want to imagine - especially in the UK (something to do with our world
>> famous management and excellent work ethic?[1]) (irony).
>
>No, I can *imagine* that. I just can't *comprehend* it.
>I.e., it just doesn't make sense from a practical standpoint.
>
>Bugs cost a *lot* more to fix (orders of magnitude) "post-release".
>
>Answering email/snailmail/phone inquiries ("support") costs far more
>than pro-actively answering those questions with good documentation.

I am not so sure if this reduces the support requests these days, but
at least with good documentation you can refer to RTFM xx.yy page
nn:-).

Even with a good documentation set, a search engine targeting the
actual manuals only (no press releases etc :-) would help finding any
usable information in many cases.

Googling is often the fastest way of finding the useful information
from a large document set (rather than going the manual tree at the
web site). This works OK for publicly available documents, but for
internal documents or extranet (for actual customers only) documents,
such engines are not always available.

From: D Yuniskis on 11 Jul 2010 01:43
Hi Paul,

Paul Keinanen wrote:
> On Sat, 10 Jul 2010 19:03:56 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>
>> Tim Watts wrote:
>
>>> Abysmal lack of testing and lack of documentation is more common than you
>>> would want to imagine - especially in the UK (something to do with our world
>>> famous management and excellent work ethic?[1]) (irony).
>> No, I can *imagine* that. I just can't *comprehend* it.
>> I.e., it just doesn't make sense from a practical standpoint.
>>
>> Bugs cost a *lot* more to fix (orders of magnitude) "post-release".
>>
>> Answering email/snailmail/phone inquiries ("support") costs far more
>> than pro-actively answering those questions with good documentation.
>
> I am not so sure if this reduces the support requests these days, but
> at least with good documentation you can refer to RTFM xx.yy page
> nn:-).

Yes, but you have to *prepare* that documentation (or, publish
the documentation that you have *previously* prepared).

If you are going to have to *eventually*, by *some* means, make
that information available to the user/customer (i.e., even if
that is forwarding an inquiry to the *developer* who looks
through his code -- because he doesn't have any OTHER documentation
for how his code is *supposed* to work!), then why not do so
to start with?

Since I've been just talking about technical information, you
can argue that it doesn't need to be "dumbed down" for a
non-technical person's perusal. E.g., the owner's manual
for your car doesn't provide detailed valve timing information;
but, the service manual for the *auto techs* does (and it
doesn't have to waste lots of text explaining how the valves
work to admit intake air, vent exhaust gases, etc.)

> Even with a good documentation set, a search engine targeting the
> actual manuals only (no press releases etc :-)

Good point ------------^^^^^^^^^^^^^^^^^

(why do companies think folks are interested in their
market-speak?)

> would help finding any
> usable information in many cases.
>
> Googling is often the fastest way of finding the useful information
> from a large document set (rather than going the manual tree at the
> web site). This works OK for publicly available documents, but for
> internal documents or extranet (for actual customers only) documents,
> such engines are not always available.
From: Paul Carpenter on 11 Jul 2010 04:03
In article <66bi361u94kim4a4071jqel2uvspcih09s(a)4ax.com>, keinanen(a)sci.fi
says...
> On Sat, 10 Jul 2010 19:03:56 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>
> >Tim Watts wrote:
>
> >> Abysmal lack of testing and lack of documentation is more common than you
> >> would want to imagine - especially in the UK (something to do with our world
> >> famous management and excellent work ethic?[1]) (irony).
> >
> >No, I can *imagine* that. I just can't *comprehend* it.
> >I.e., it just doesn't make sense from a practical standpoint.
> >
> >Bugs cost a *lot* more to fix (orders of magnitude) "post-release".
> >
> >Answering email/snailmail/phone inquiries ("support") costs far more
> >than pro-actively answering those questions with good documentation.
>
> I am not so sure if this reduces the support requests these days, but
> at least with good documentation you can refer to RTFM xx.yy page
> nn:-).

Which is still better than finding out it is on some hidden FAQ document,
or some application note which is not referenced from anywhere else
and has a title that is in internal speak.

e.g. "How to do xx with product range 'Turbo widget wangler'"

When the product range you are looking at is "Wibbling anchovies".

There are a few manufacturers that are 'good' at that for silicon.

> Even with a good documentation set, a search engine targeting the
> actual manuals only (no press releases etc :-) would help finding any
> usable information in many cases.

Yes the referencing and search facilities are only as good as the
consistent naming policy.

I am reminded of one product over 20 years ago that referred to a
group of switches on one board by THREE different names in the

circuit diagram
user manual
test programme

> Googling is often the fastest way of finding the useful information
> from a large document set (rather than going the manual tree at the
> web site). This works OK for publicly available documents, but for
> internal documents or extranet (for actual customers only) documents,
> such engines are not always available.

Often internal serach engines only search title and short description
not the whole document.

--
Paul Carpenter | paul(a)pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
From: Paul Carpenter on 11 Jul 2010 04:09
In article <i1blhi$v33$1(a)speranza.aioe.org>, not.going.to.be(a)seen.com
says...
> Hi Paul,
>
> Paul Keinanen wrote:
....
> > Even with a good documentation set, a search engine targeting the
> > actual manuals only (no press releases etc :-)
>
> Good point ------------^^^^^^^^^^^^^^^^^
>
> (why do companies think folks are interested in their
> market-speak?)

Because the people controlling the web sites, are usually marketing
and investor relations, so they think the ONLY people who visit the
web site are investors and the press. Products and actual sales/support
information is way down the list or has to be with login after NDA
exchange.

Do you remember the NXP website relaunch which meant it was difficult
to get into the NXP site to even find a product about a year ago.

Too often i have had to do NDA exchange to get information that is
less than a datasheet, more a product brief.

--
Paul Carpenter | paul(a)pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Unique ID in the application code
Next: Eclipse CDT vendor?