Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6820 > unrolled thread

To hell with the program spec - I know what's best

Back to article view | Back to comp.programming

Contents

  To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-26 07:24 +0100
    Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-26 13:42 +0100
      Re: To hell with the program spec - I know what's best Ike Naar <ike@iceland.freeshell.org> - 2016-07-26 13:23 +0000
        Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-26 14:51 +0100
          Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-26 22:29 -0400
      Re: To hell with the program spec - I know what's best David Brown <david.brown@hesbynett.no> - 2016-07-26 16:53 +0200
    Re: To hell with the program spec - I know what's best Julio Di Egidio <julio@diegidio.name> - 2016-07-26 06:29 -0700
    Re: To hell with the program spec - I know what's best David Brown <david.brown@hesbynett.no> - 2016-07-26 15:41 +0200
      Re: To hell with the program spec - I know what's best Julio Di Egidio <julio@diegidio.name> - 2016-07-26 10:08 -0700
    Re: To hell with the program spec - I know what's best "Ant" <not@home.today> - 2016-07-26 19:50 +0100
      Re: To hell with the program spec - I know what's best "Osmium" <r124c4u102@comcast.net> - 2016-07-26 14:32 -0500
    Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-26 22:26 -0400
      Re: To hell with the program spec - I know what's best Kaz Kylheku <349-534-5780@kylheku.com> - 2016-07-27 03:57 +0000
        Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 08:21 +0100
          Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:43 -0400
            Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 12:12 +0100
        Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:40 -0400
      Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 08:10 +0100
        Re: To hell with the program spec - I know what's best BartC <bc@freeuk.com> - 2016-07-27 11:04 +0100
          Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 14:05 +0100
            Re: To hell with the program spec - I know what's best BartC <bc@freeuk.com> - 2016-07-27 18:21 +0100
              Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 18:56 +0100
            Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:51 -0400
              Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 12:26 +0100
          Re: To hell with the program spec - I know what's best Wally W. <ww84wa@aim.com> - 2016-07-27 19:51 -0400
            Re: To hell with the program spec - I know what's best "Osmium" <r124c4u102@comcast.net> - 2016-07-27 22:37 -0500
              Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 07:28 +0100
                Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:54 -0400
              Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:53 -0400
                Re: To hell with the program spec - I know what's best Wally W. <ww84wa@aim.com> - 2016-07-28 08:38 -0400
        Re: To hell with the program spec - I know what's best Öö Tiib <ootiib@hot.ee> - 2016-07-27 05:52 -0700
        Re: To hell with the program spec - I know what's best "J. Clarke" <j.clarke.873638@gmail.com> - 2016-07-28 06:48 -0400
          Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 12:21 +0100
            Re: To hell with the program spec - I know what's best Wally W. <ww84wa@aim.com> - 2016-07-28 08:47 -0400
              Re: To hell with the program spec - I know what's best Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-28 16:13 -0500
                Re: To hell with the program spec - I know what's best Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 22:38 +0100

Page 1 of 2  [1] 2  Next page →

#6820 — To hell with the program spec - I know what's best

In a recent discussion, the idea of working to a program specification 
came up. It was ridiculed in one quarter, and defended in others.

Just now, I stumbled across a rather curious example of spec violation:

http://www.programiz.com/c-programming/examples/print-sentence

The page title, and indeed the top header, read:

-------------------------
C "Hello, World!" Program
-------------------------

Okay, we know what that's all about. It's a tutorial. Okay. The tutorial 
goes on to give the spec a little more flesh. What, precisely, are we 
going to demonstrate?

-------------------------
A simple C program to display "Hello, World!" on the screen. Since, it's 
a very simple program, it is often used to illustrate the syntax of a 
programming language.
-------------------------

Fine. We're going to write "Hello, World!" on the... well, the spec says 
"the screen". Let's hope the user doesn't redirect their output, then.

The page's author then goes on to assure us that the program spec hasn't 
changed, before displaying the actual code:

-------------------------
Program to Display "Hello, World!"
-------------------------

And now, after the big build-up, the Finale:

-------------------------
#include <stdio.h>
int main()
{
    // printf() displays the string inside quotation
    printf("C Programming");
    return 0;
}
-------------------------

Oops.

The trouble with not sticking to the spec is that you don't meet the 
clients' expectations, and it's the client that pays the bills. If you 
don't do what is asked, the client may well be in a position to refuse 
to pay for the work. The same applies to anything you did do that was 
/not/ asked for.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [next] | [standalone]

#6822

On 26/07/16 11:28, Stefan Ram wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> The trouble with not sticking to the spec is that you don't meet the
>> clients' expectations, and it's the client that pays the bills. If you
>> don't do what is asked, the client may well be in a position to refuse
>> to pay for the work. The same applies to anything you did do that was
>> /not/ asked for.
>
>    Or worse, when you are taking an exam, and the requirement is
>    to write a program that prints »hello, world«, and you turn in
>    a program that prints »C programming«, you might get worse grades!
>
>    What grade should a student deserve when the requirement is to
>    write a program that prints »hello, world«, and his program
>    prints »Hello world!«?

Good question. In my book, he'd lose a mark (not three marks) out of 
ten, but I'd still give him an A if everything else was perfect. It's a 
very minor fault. But to change the message completely would lead me to 
fail him. And if he included anything that wasn't in the spec, he'd lose 
marks for that, too.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6823

On 2016-07-26, Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 26/07/16 11:28, Stefan Ram wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> The trouble with not sticking to the spec is that you don't meet the
>>> clients' expectations, and it's the client that pays the bills. If you
>>> don't do what is asked, the client may well be in a position to refuse
>>> to pay for the work. The same applies to anything you did do that was
>>> /not/ asked for.
>>
>>    Or worse, when you are taking an exam, and the requirement is
>>    to write a program that prints ?hello, world?, and you turn in
>>    a program that prints ?C programming?, you might get worse grades!
>>
>>    What grade should a student deserve when the requirement is to
>>    write a program that prints ?hello, world?, and his program
>>    prints ?Hello world!??
>
> Good question. In my book, he'd lose a mark (not three marks) out of 
> ten, but I'd still give him an A if everything else was perfect. It's a 
> very minor fault. But to change the message completely would lead me to 
> fail him. And if he included anything that wasn't in the spec, he'd lose 
> marks for that, too.

Smart programmers, if they are naive, deliver software that just works.
If they aren't naive, they deliver software that almost works, plus an
expensive maintenance contract for future enhancements.

[toc] | [prev] | [next] | [standalone]

#6826

On 26/07/16 14:23, Ike Naar wrote:
<snip>
>
> Smart programmers, if they are naive, deliver software that just works.
> If they aren't naive, they deliver software that almost works, plus an
> expensive maintenance contract for future enhancements.

Words fail me.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6835

In article <nn7pt1$daj$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 26/07/16 14:23, Ike Naar wrote:
> <snip>
> >
> > Smart programmers, if they are naive, deliver software that just works.
> > If they aren't naive, they deliver software that almost works, plus an
> > expensive maintenance contract for future enhancements.
> 
> Words fail me.

One wishes that they failed the people who run this sort of business, 
but they don't.

[toc] | [prev] | [next] | [standalone]

#6829

On 26/07/16 16:13, Stefan Ram wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 26/07/16 11:28, Stefan Ram wrote:
>>> What grade should a student deserve when the requirement is to
>>> write a program that prints »hello, world«, and his program
>>> prints »Hello world!«?
>> Good question. In my book, he'd lose a mark (not three marks) out of 
>> ten, but I'd still give him an A if everything else was perfect. It's a 
>> very minor fault. But to change the message completely would lead me to 
>> fail him. And if he included anything that wasn't in the spec, he'd lose 
>> marks for that, too.
> 
>   1st remark
> 
>   A requirement for a program might ask to print a word with
>   an wrong spelling, such as »requierment«. But when this is
>   needed for a spelling quiz program, it is important that the
>   programmer does not »correct« it into the »correct« spelling.
> 

If your development process does not allow for people down the chain
(the programmer in this case) to question the requirements, leading to
corrections for this kind of mistake, then your development process is
probably broken.

Clearly the programmer cannot take it upon himself to correct the
spelling here - perhaps there is a good reason for specifying the
spelling in question.  But he/she should be able to raise the issue.

Obviously in the case of an exam, there is no scope for such feedback.
I would expect a good answer to print the specified incorrect spelling -
but the code should have comments explaining this and with a "TODO"
comment saying the requirements here should be confirmed.  In a
real-life situation, if it is not possible to question the requirements,
then an issue like this should be clearly notified in the delivery
documentation.

[toc] | [prev] | [next] | [standalone]

#6824

On Tuesday, July 26, 2016 at 8:24:27 AM UTC+2, Richard Heathfield wrote:
> 
> In a recent discussion, the idea of working to a program specification 
> came up. It was ridiculed in one quarter, and defended in others.

Good question.  There is not much debate: the (engineering) definition of Quality is "the degree of correspondence of a product to its requirements" (where requirements are both explicit and implicit, so everything is covered).  Then the answer to the above question becomes obvious and in fact necessary.

<snip>
> If you 
> don't do what is asked, the client may well be in a position to refuse 
> to pay for the work. The same applies to anything you did do that was 
> /not/ asked for.

No, we can and when possible do put some added value in, to make the customer happier.  Of course, it is not about inventing additional requirements, it is more about the level at which requirements get implemented.

Julio

[toc] | [prev] | [next] | [standalone]

#6825

On 26/07/16 08:24, Richard Heathfield wrote:
> In a recent discussion, the idea of working to a program specification
> came up. It was ridiculed in one quarter, and defended in others.
> 
> 
> The trouble with not sticking to the spec is that you don't meet the
> clients' expectations, and it's the client that pays the bills. If you
> don't do what is asked, the client may well be in a position to refuse
> to pay for the work. The same applies to anything you did do that was
> /not/ asked for.
> 

The trick is to persuade the customer that they are not qualified to
write the specification (very few customers /are/ qualified to write a
spec properly).  So you offer to do that too.

This way the customer writes a "requirements specification" with loser
terms, such as "Write a program that displays a simple message".

/You/ then write the software specification, "Write a simple C program
that displays Hello, World!".  The customer signs off on the software
specification, and you get paid for writing that.

Then you write the code.  Since you wrote the spec, you presumably wrote
it knowing you have a reasonable chance of actually writing matching
code.  But suppose you didn't - perhaps your code prints out "C
Programming".  Then you change your software specification to match,
release that as specification document 1.01, and get paid for
maintenance of the specification document as well as for writing the
program.  It all still matches the customer's actual requirements, and
the software specification and the code are synchronised.  Everyone is
happy :-)

More generally, there is a continuous progression from "I want a program
to solve my problem" down to the actual final code.  There are no fixed
points to say "this is the requirements", "this is the design
specification", "this is the code specification", "this is the
functional model", "this is the prototype code", etc.  The key to doing
the work successfully is to get the right level of detail at the right
place, choosing carefully where you keep things open and where you flesh
out all the details, and being sure of which parts are open to change
and who can change them.

[toc] | [prev] | [next] | [standalone]

#6830

On Tuesday, July 26, 2016 at 3:41:47 PM UTC+2, David Brown wrote:
> On 26/07/16 08:24, Richard Heathfield wrote:
> > In a recent discussion, the idea of working to a program specification
> > came up. It was ridiculed in one quarter, and defended in others.
> > 
> > The trouble with not sticking to the spec is that you don't meet the
> > clients' expectations, and it's the client that pays the bills. If you
> > don't do what is asked, the client may well be in a position to refuse
> > to pay for the work. The same applies to anything you did do that was
> > /not/ asked for.
> 
> The trick is to persuade the customer that they are not qualified to
> write the specification (very few customers /are/ qualified to write a
> spec properly).  So you offer to do that too.

That is not a trick, that is how it should be: it's called Analysis, and not only because the customer is not an expert, there are also serious technical implications, down to what some call the restaurant kitchen model.

Rather, the expungement of analysis proper is one of the *major* problems with Agility as promoted and practiced for almost 20 years now.  (And, for example, working for a PO as in SCRUM does not necessarily mean, and usually does not mean, any actual analysis is happening.)

Just to begin with, back to the OP (and the definition of Quality I gave earlier), no analysis entails no quality: anyway, as hinted at above, the implications are huge.

Julio

[toc] | [prev] | [next] | [standalone]

#6831

"Richard Heathfield" wrote:

> Just now, I stumbled across a rather curious example of spec violation

> Program to Display "Hello, World!"

> printf("C Programming");

I am so used to the idea of "hello world" being a metaphor for the
first program written in a language you are learning which displays
something, that on first read of your post I couldn't see the
problem. Despite the output being different from what was stated I
thought "so, it's a hello-world program". I expect the author had a
similar brain-fart.

[toc] | [prev] | [next] | [standalone]

#6832

"Ant" wrote:

> "Richard Heathfield" wrote:
> 
>> Just now, I stumbled across a rather curious example of spec violation
> 
>> Program to Display "Hello, World!"
> 
>> printf("C Programming");
> 
> I am so used to the idea of "hello world" being a metaphor for the
> first program written in a language you are learning which displays
> something, that on first read of your post I couldn't see the
> problem. Despite the output being different from what was stated I
> thought "so, it's a hello-world program". I expect the author had a
> similar brain-fart.

Tsk, tsk, tsk. 

[toc] | [prev] | [next] | [standalone]

#6834

In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
berlin.de says...
> 
> Richard Heathfield <rjh@cpax.org.uk> writes:
> >The trouble with not sticking to the spec is that you don't meet the 
> >clients' expectations, and it's the client that pays the bills. If you 
> >don't do what is asked, the client may well be in a position to refuse 
> >to pay for the work. The same applies to anything you did do that was 
> >/not/ asked for.
> 
>   Or worse, when you are taking an exam, and the requirement is
>   to write a program that prints »hello, world«, and you turn in
>   a program that prints »C programming«, you might get worse grades!
> 
>   What grade should a student deserve when the requirement is to
>   write a program that prints »hello, world«, and his program
>   prints »Hello world!«?

What grade would one get if in addition to the program that prints 
"hello, world", the student provided an installation program, an 
uninstallation program, and a set of bound documentation clearly 
describing the use of both the "hello, world" program and the 
installer/uninstaller?

That's the kind of "deviation from spec" that we're talking about, 
however Heathfield doesn't seem to understand the difference between 
that and providing a broken program.

[toc] | [prev] | [next] | [standalone]

#6836

On 2016-07-27, J. Clarke <j.clarke.873638@gmail.com> wrote:
> In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
> berlin.de says...
>> 
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> >The trouble with not sticking to the spec is that you don't meet the 
>> >clients' expectations, and it's the client that pays the bills. If you 
>> >don't do what is asked, the client may well be in a position to refuse 
>> >to pay for the work. The same applies to anything you did do that was 
>> >/not/ asked for.
>> 
>>   Or worse, when you are taking an exam, and the requirement is
>>   to write a program that prints »hello, world«, and you turn in
>>   a program that prints »C programming«, you might get worse grades!
>> 
>>   What grade should a student deserve when the requirement is to
>>   write a program that prints »hello, world«, and his program
>>   prints »Hello world!«?
>
> What grade would one get if in addition to the program that prints 
> "hello, world", the student provided an installation program, an 
> uninstallation program, and a set of bound documentation clearly 
> describing the use of both the "hello, world" program and the 
> installer/uninstaller?
>
> That's the kind of "deviation from spec" that we're talking about, 
> however Heathfield doesn't seem to understand the difference between 
> that and providing a broken program.

That's not deviation from the spec, unless the spec expressly forbids
other non-conflicting requirements from being thrown in and implement.

I think Richard understands that, say, an ISO C implementation can come
with a lovely IDE and leather-bound manual, and be conforming.

[toc] | [prev] | [next] | [standalone]

#6839

On 27/07/16 04:57, Kaz Kylheku wrote:
> On 2016-07-27, J. Clarke <j.clarke.873638@gmail.com> wrote:
>> In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
>> berlin.de says...
>>>
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>> The trouble with not sticking to the spec is that you don't meet the
>>>> clients' expectations, and it's the client that pays the bills. If you
>>>> don't do what is asked, the client may well be in a position to refuse
>>>> to pay for the work. The same applies to anything you did do that was
>>>> /not/ asked for.
>>>
>>>    Or worse, when you are taking an exam, and the requirement is
>>>    to write a program that prints »hello, world«, and you turn in
>>>    a program that prints »C programming«, you might get worse grades!
>>>
>>>    What grade should a student deserve when the requirement is to
>>>    write a program that prints »hello, world«, and his program
>>>    prints »Hello world!«?
>>
>> What grade would one get if in addition to the program that prints
>> "hello, world", the student provided an installation program, an
>> uninstallation program, and a set of bound documentation clearly
>> describing the use of both the "hello, world" program and the
>> installer/uninstaller?
>>
>> That's the kind of "deviation from spec" that we're talking about,
>> however Heathfield doesn't seem to understand the difference between
>> that and providing a broken program.
>
> That's not deviation from the spec, unless the spec expressly forbids
> other non-conflicting requirements from being thrown in and implement.
>
> I think Richard understands that, say, an ISO C implementation can come
> with a lovely IDE and leather-bound manual, and be conforming.

Yes, but Richard also understands that the customer is not obliged to 
pay for things he hasn't ordered or agreed to.

A client asks for a program that compares the outputs of two test runs, 
looking for regression test failures in a roll-up calculation. The 
contractor spends a day writing that software, and another half-day 
developing an installer/uninstaller for it. The contractor bills the 
client for 1.5 days of work. But alas! The auditors are in, and a spot 
check is performed. The contractor's attempt to defraud the client out 
of contractor_rate_per_hour * 4 is spotted, and his contract is 
terminated on the grounds of fraud. You see, the client didn't want an 
installer. The client didn't need an installer. The client just wanted a 
regression test comparison tool for roll-up calcs. That's what he asked 
for, and that's what should have been delivered.

There is nothing wrong with saying to a client "I can do what you ask, 
and in addition you might want to consider X, Y, and Z, for 
such-and-such reasons. It will take no more than H hours and cost no 
more than P pounds." But to assume that the client is too stupid to know 
what he wants and too gullible to spot that he's being fleeced is a 
very, very unwise course to steer.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6850

In article <nn9ndi$7tl$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 27/07/16 04:57, Kaz Kylheku wrote:
> > On 2016-07-27, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >> In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
> >> berlin.de says...
> >>>
> >>> Richard Heathfield <rjh@cpax.org.uk> writes:
> >>>> The trouble with not sticking to the spec is that you don't meet the
> >>>> clients' expectations, and it's the client that pays the bills. If you
> >>>> don't do what is asked, the client may well be in a position to refuse
> >>>> to pay for the work. The same applies to anything you did do that was
> >>>> /not/ asked for.
> >>>
> >>>    Or worse, when you are taking an exam, and the requirement is
> >>>    to write a program that prints »hello, world«, and you turn in
> >>>    a program that prints »C programming«, you might get worse grades!
> >>>
> >>>    What grade should a student deserve when the requirement is to
> >>>    write a program that prints »hello, world«, and his program
> >>>    prints »Hello world!«?
> >>
> >> What grade would one get if in addition to the program that prints
> >> "hello, world", the student provided an installation program, an
> >> uninstallation program, and a set of bound documentation clearly
> >> describing the use of both the "hello, world" program and the
> >> installer/uninstaller?
> >>
> >> That's the kind of "deviation from spec" that we're talking about,
> >> however Heathfield doesn't seem to understand the difference between
> >> that and providing a broken program.
> >
> > That's not deviation from the spec, unless the spec expressly forbids
> > other non-conflicting requirements from being thrown in and implement.
> >
> > I think Richard understands that, say, an ISO C implementation can come
> > with a lovely IDE and leather-bound manual, and be conforming.
> 
> Yes, but Richard also understands that the customer is not obliged to 
> pay for things he hasn't ordered or agreed to.
> 
> A client asks for a program that compares the outputs of two test runs, 
> looking for regression test failures in a roll-up calculation. The 
> contractor spends a day writing that software, and another half-day 
> developing an installer/uninstaller for it. The contractor bills the 
> client for 1.5 days of work. But alas! The auditors are in, and a spot 
> check is performed. The contractor's attempt to defraud the client out 
> of contractor_rate_per_hour * 4 is spotted, and his contract is 
> terminated on the grounds of fraud. You see, the client didn't want an 
> installer. The client didn't need an installer. The client just wanted a 
> regression test comparison tool for roll-up calcs. That's what he asked 
> for, and that's what should have been delivered.
> 
> There is nothing wrong with saying to a client "I can do what you ask, 
> and in addition you might want to consider X, Y, and Z, for 
> such-and-such reasons. It will take no more than H hours and cost no 
> more than P pounds." But to assume that the client is too stupid to know 
> what he wants and too gullible to spot that he's being fleeced is a 
> very, very unwise course to steer.

So why would an installer/uninstaller be needed for a program that is 
used once?

The original discussion was in the context of software that reasonably 
might be installed by someone other than the original programmer.  I 
don't write installer/uninstallers for programs that I am going to use 
once or twice and toss but that is not the context of the original 
discussion.

[toc] | [prev] | [next] | [standalone]

#6855

On 28/07/16 11:43, J. Clarke wrote:
> In article <nn9ndi$7tl$1@dont-email.me>, rjh@cpax.org.uk says...
>>
>> On 27/07/16 04:57, Kaz Kylheku wrote:
>>> On 2016-07-27, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>> In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
>>>> berlin.de says...
>>>>>
>>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>>> The trouble with not sticking to the spec is that you don't meet the
>>>>>> clients' expectations, and it's the client that pays the bills. If you
>>>>>> don't do what is asked, the client may well be in a position to refuse
>>>>>> to pay for the work. The same applies to anything you did do that was
>>>>>> /not/ asked for.
>>>>>
>>>>>     Or worse, when you are taking an exam, and the requirement is
>>>>>     to write a program that prints »hello, world«, and you turn in
>>>>>     a program that prints »C programming«, you might get worse grades!
>>>>>
>>>>>     What grade should a student deserve when the requirement is to
>>>>>     write a program that prints »hello, world«, and his program
>>>>>     prints »Hello world!«?
>>>>
>>>> What grade would one get if in addition to the program that prints
>>>> "hello, world", the student provided an installation program, an
>>>> uninstallation program, and a set of bound documentation clearly
>>>> describing the use of both the "hello, world" program and the
>>>> installer/uninstaller?
>>>>
>>>> That's the kind of "deviation from spec" that we're talking about,
>>>> however Heathfield doesn't seem to understand the difference between
>>>> that and providing a broken program.
>>>
>>> That's not deviation from the spec, unless the spec expressly forbids
>>> other non-conflicting requirements from being thrown in and implement.
>>>
>>> I think Richard understands that, say, an ISO C implementation can come
>>> with a lovely IDE and leather-bound manual, and be conforming.
>>
>> Yes, but Richard also understands that the customer is not obliged to
>> pay for things he hasn't ordered or agreed to.
>>
>> A client asks for a program that compares the outputs of two test runs,
>> looking for regression test failures in a roll-up calculation. The
>> contractor spends a day writing that software, and another half-day
>> developing an installer/uninstaller for it. The contractor bills the
>> client for 1.5 days of work. But alas! The auditors are in, and a spot
>> check is performed. The contractor's attempt to defraud the client out
>> of contractor_rate_per_hour * 4 is spotted, and his contract is
>> terminated on the grounds of fraud. You see, the client didn't want an
>> installer. The client didn't need an installer. The client just wanted a
>> regression test comparison tool for roll-up calcs. That's what he asked
>> for, and that's what should have been delivered.
>>
>> There is nothing wrong with saying to a client "I can do what you ask,
>> and in addition you might want to consider X, Y, and Z, for
>> such-and-such reasons. It will take no more than H hours and cost no
>> more than P pounds." But to assume that the client is too stupid to know
>> what he wants and too gullible to spot that he's being fleeced is a
>> very, very unwise course to steer.
>
> So why would an installer/uninstaller be needed for a program that is
> used once?

I don't know where you got 'once' from. The regression test comparison 
program I based my example on was used /daily/ for several months, by 
several different developers. But you're right anyway - why /would/ you 
write an installer/uninstaller for a one-off program? It's just daft.

> The original discussion was in the context of software that reasonably
> might be installed by someone other than the original programmer.

The point of my example was to show that there are environments in which 
installers are inappropriate, and the real world program on which that 
example was based /was/ installed by a number of people other than the 
original programmer. It wasn't hard to install. Copy, and you're done.


> I
> don't write installer/uninstallers for programs that I am going to use
> once or twice and toss but that is not the context of the original
> discussion.

And I don't write installers/uninstallers for programs that will be used 
a great many times by lots of people /unless/ to do so makes more sense 
than not to do so. That's a decision I make on a case-by-case basis. 
But, wherever possible and sensible, I design programs in such a way as 
to minimise their impact on their environment. I try, where possible, to 
avoid the registry. Why? Because the registry is probably already 
chock-full of junk, and the last thing the user needs is for me to add 
more. But if my program /has/ to use the registry, so be it. I know how 
to do it - in fact, it's laughably easy - but it's just something I try 
to avoid. Mostly because I like the idea of being able to use a program 
without first having to sew it into the lining of the OS. And partly 
because I like the idea of being able to remove a program from the 
system without the need for scissors.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6849

In article <20160726205628.362@kylheku.com>, 349-534-5780@kylheku.com 
says...
> 
> On 2016-07-27, J. Clarke <j.clarke.873638@gmail.com> wrote:
> > In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
> > berlin.de says...
> >> 
> >> Richard Heathfield <rjh@cpax.org.uk> writes:
> >> >The trouble with not sticking to the spec is that you don't meet the 
> >> >clients' expectations, and it's the client that pays the bills. If you 
> >> >don't do what is asked, the client may well be in a position to refuse 
> >> >to pay for the work. The same applies to anything you did do that was 
> >> >/not/ asked for.
> >> 
> >>   Or worse, when you are taking an exam, and the requirement is
> >>   to write a program that prints »hello, world«, and you turn in
> >>   a program that prints »C programming«, you might get worse grades!
> >> 
> >>   What grade should a student deserve when the requirement is to
> >>   write a program that prints »hello, world«, and his program
> >>   prints »Hello world!«?
> >
> > What grade would one get if in addition to the program that prints 
> > "hello, world", the student provided an installation program, an 
> > uninstallation program, and a set of bound documentation clearly 
> > describing the use of both the "hello, world" program and the 
> > installer/uninstaller?
> >
> > That's the kind of "deviation from spec" that we're talking about, 
> > however Heathfield doesn't seem to understand the difference between 
> > that and providing a broken program.
> 
> That's not deviation from the spec, unless the spec expressly forbids
> other non-conflicting requirements from being thrown in and implement.
> 
> I think Richard understands that, say, an ISO C implementation can come
> with a lovely IDE and leather-bound manual, and be conforming.

His argument originally was that writing the installer/uninstaller 
wasn't in the spec.

[toc] | [prev] | [next] | [standalone]

#6838

On 27/07/16 03:26, J. Clarke wrote:
> In article <exam-20160726112224@ram.dialup.fu-berlin.de>, ram@zedat.fu-
> berlin.de says...
>>
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> The trouble with not sticking to the spec is that you don't meet the
>>> clients' expectations, and it's the client that pays the bills. If you
>>> don't do what is asked, the client may well be in a position to refuse
>>> to pay for the work. The same applies to anything you did do that was
>>> /not/ asked for.
>>
>>    Or worse, when you are taking an exam, and the requirement is
>>    to write a program that prints »hello, world«, and you turn in
>>    a program that prints »C programming«, you might get worse grades!
>>
>>    What grade should a student deserve when the requirement is to
>>    write a program that prints »hello, world«, and his program
>>    prints »Hello world!«?
>
> What grade would one get if in addition to the program that prints
> "hello, world", the student provided an installation program, an
> uninstallation program, and a set of bound documentation clearly
> describing the use of both the "hello, world" program and the
> installer/uninstaller?

The grade should be D- (and for very good reason).

> That's the kind of "deviation from spec" that we're talking about,
> however Heathfield doesn't seem to understand the difference between
> that and providing a broken program.

Mr Clarke, you seem to think that you have sole charge of the client's 
cheque book.

The creation of software takes time, effort, and money. The money has to 
come from somewhere, and (from the software developer's perspective at 
least) it comes from the client. And I realise it's a tricky concept, 
but it's true: He who pays the piper calls the tune.

If the client wants an installer/uninstaller, he'll ask for it. Since he 
didn't ask for it, he sure as hell isn't liable to pay for it. If you 
charge him for it anyway, he has the right to refuse. If it went to 
court, he'd win.

If, however, the "hello, world" student were to add a comment to his 
answer to the effect that he could on request provide an 
installer/uninstaller and that it would take no more than H hours and 
cost no more than P pounds, then he would receive full credit for that 
worthy answer.

Now please stop being such an ass. It is perfectly possible for two 
people who disagree to have a /civil/ conversation. Why not give it a try?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#6840

On 27/07/2016 08:10, Richard Heathfield wrote:
> On 27/07/16 03:26, J. Clarke wrote:

>> What grade would one get if in addition to the program that prints
>> "hello, world", the student provided an installation program, an
>> uninstallation program, and a set of bound documentation clearly
>> describing the use of both the "hello, world" program and the
>> installer/uninstaller?
>
> The grade should be D- (and for very good reason).

>
> Mr Clarke, you seem to think that you have sole charge of the client's
> cheque book.
>
> The creation of software takes time, effort, and money. The money has to
> come from somewhere, and (from the software developer's perspective at
> least) it comes from the client. And I realise it's a tricky concept,
> but it's true: He who pays the piper calls the tune.
>
> If the client wants an installer/uninstaller, he'll ask for it. Since he
> didn't ask for it, he sure as hell isn't liable to pay for it.

Such things ought to be assumed to be part of any application anyway. 
Otherwise the client might now pay anything if they can't figure out how 
to get it and use it.

Taken even the trivial program you mentioned in your OP. How is it going 
to be distributed to the client: as sources, or as a pre-built binary? 
What platform does the client have? It might have to run on multiple 
hardware. What pre-installed software is assumed?

And how exactly is it going to get from the developer's machine to the 
client's? Flying an installation and briefing team to the client's site 
might be an unreasonable expense if not authorised, but /something/ is 
needed as the client may not have anyone with the technical expertise to 
deal with such issues.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6843

On 27/07/16 11:04, BartC wrote:
> On 27/07/2016 08:10, Richard Heathfield wrote:
>> On 27/07/16 03:26, J. Clarke wrote:
>
>>> What grade would one get if in addition to the program that prints
>>> "hello, world", the student provided an installation program, an
>>> uninstallation program, and a set of bound documentation clearly
>>> describing the use of both the "hello, world" program and the
>>> installer/uninstaller?
>>
>> The grade should be D- (and for very good reason).
>
>>
>> Mr Clarke, you seem to think that you have sole charge of the client's
>> cheque book.
>>
>> The creation of software takes time, effort, and money. The money has to
>> come from somewhere, and (from the software developer's perspective at
>> least) it comes from the client. And I realise it's a tricky concept,
>> but it's true: He who pays the piper calls the tune.
>>
>> If the client wants an installer/uninstaller, he'll ask for it. Since he
>> didn't ask for it, he sure as hell isn't liable to pay for it.
>
> Such things ought to be assumed to be part of any application anyway.

I fundamentally disagree with this. It ought to be assumed to be part of 
/some/ applications, but not of /any/ applications.

> Otherwise the client might now pay anything if they can't figure out how
> to get it and use it.

Okay, let's take a case in point, shall we? You have been hired by an 
airline to write a program to analyse flight segment data supplied by 
various ticketing agencies around the world. The problem: lots of people 
fly from A to B, and lots of people fly from B to C, and lots of people 
fly from C to D. If routes A-B, B-C, and C-D were scrapped and replaced 
with direct flights from A-D, would that increase revenue, or decrease 
it? The answer is that it depends whether B and C are genuine 
destinations or whether they are just irritating "bus stops" where 
nobody gets off or on the aircraft.

(You might think the ticketing agency already supplies complete journey 
information, but you'd be wrong. Or you might think that the airline 
already has a program to do this analysis, in which case you'd be right 
in at least one case!)

The customer (the airline) requires you to provide the program in ISO C. 
It will be tested by another contractor over whom you have no control 
(and whom you might never meet).

You write the program. You also write an installer and an uninstaller. 
The installer adds shortcuts and a tray icon; it sets up file 
associations in the registry; and it adjusts the PATH environment 
variable, also in the registry. Fantastic!

You hand it in to the client, along with your itemised bill. Program: 
$X. Installer: $Y. Tax: $Tx + Ty. Total: $(X+Y+Tx+Ty). The client FTPs 
the ISO C code to the test engineer, who tests it on his Unix system. 
Once the test engineer has pronounced that he is satisfied with the 
basic functionality of the code, it is sent over the wire to the IBM 
mainframe, where resident experts will write JCL to control the 
program's environment. The program will undergo further testing on the 
mainframe, and then (all being well) it will be signed off and will go 
into the production environment.

It comes to sign-off time. The program works well, so that's fine. You 
did a good job there. But then the client (who hasn't signed yet) 
notices that you've written a completely pointless installer for 
Windows, an OS on which the program will never be installed. He gives it 
back to you, and adjusts the bill to $X + $Xt before signing it off.

All that work on the installer, and for nothing. Pointless and stupid.

> Taken even the trivial program you mentioned in your OP. How is it going
> to be distributed to the client: as sources, or as a pre-built binary?

It's a hello world program. Why would it need to be distributed? The 
whole point of hello world programs is that you write them /yourself/ 
and get them running /yourself/!

> What platform does the client have?

GOOD question! The spec will tell you that, if you can be bothered to 
read it. Let's say it's MVS (or OS/390 or whatever they call it 
nowadays). Are you going to write an installer for that? Or VM/CMS? Or 
Beos? Or OS/2?

> It might have to run on multiple
> hardware. What pre-installed software is assumed?

The client can very often answer all these questions, because the client 
is very often the IT department of a large corporation. They didn't hire 
you because they can't write the code themselves. They hired you to 
speed things up a bit by providing extra resource. In any case, the spec 
will answer these questions for you. If it's your job to write the spec, 
and assuming that you don't already know the answer, it becomes your job 
to find out from the client the answers to these questions.

> And how exactly is it going to get from the developer's machine to the
> client's? Flying an installation and briefing team to the client's site
> might be an unreasonable expense if not authorised, but /something/ is
> needed as the client may not have anyone with the technical expertise to
> deal with such issues.

No, something /might/ be needed because the client /may/ not have anyone 
with the technical expertise. The point is that you don't /assume/ it. 
You /find out/.

In other words, if the program spec doesn't call for an installer, it's 
reasonable to ask whether one is required. But it is /not/ reasonable to 
/assume/ that one is required. That's just sloppy thinking.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web