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 2 of 2 — ← Prev page 1 [2]

#6844

On 27/07/2016 14:05, Richard Heathfield wrote:
> On 27/07/16 11:04, BartC wrote:
>> On 27/07/2016 08:10, Richard Heathfield wrote:

>>> 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.

<snip long example>

> You hand it in to the client,

How and in what form? How to do they activate and configure it? How do 
they use it? How do they install another copy? How to troubleshoot if it 
doesn't work? What are the deviations from the spec?

This is what I'm talking about.

> 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.

Which is very unlikely to happen as a program that works in Linux is 
unlikely to work unchanged in Windows, even if supplied as source.

(Except perhaps for a basic console app that only does file i/o. But 
then gcc is exactly such an app which apparently took years to make it 
to Windows.)

Also because the developer wouldn't be that 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/!

Nevertheless, how /would/ even that program be distributed? See, I'm 
extended the scope of Hello, World from an example suitable for testing 
a language installation, to also being an example of an application to 
be distributed.

-- 
Bartc

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

#6845

On 27/07/16 18:21, BartC wrote:
> On 27/07/2016 14:05, Richard Heathfield wrote:
>> On 27/07/16 11:04, BartC wrote:
>>> On 27/07/2016 08:10, Richard Heathfield wrote:
>
>>>> 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.
>
> <snip long example>
>
>> You hand it in to the client,
>
> How and in what form?

The client and the developer form a contract, in which they agree on a 
set of tasks that the developer will perform, and the developer performs 
those tasks in return for remuneration from the client. The precise 
nature of the hand-over process will form part of that contract.

> How to do they activate and configure it?  How do they use it? How
 > do they install another copy? How to troubleshoot if it
> doesn't work? What are the deviations from the spec?

All of these are very important questions indeed, and the answers to all 
of them should be established as part of the requirements phase of 
construction.

> This is what I'm talking about.
>
>> 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.
>
> Which is very unlikely to happen as a program that works in Linux is
> unlikely to work unchanged in Windows, even if supplied as source.

The claim I am disputing is the claim that one should, as a matter of 
course, write an installer/uninstaller. When you are asked, for example, 
to provide source code in ISO C, you can be reasonably sure that the 
client will be fairly unhappy if he discovers that you've written it in 
Windows C or Linux C or MacOS C. If he'd wanted you to target a specific 
platform, he'd have told you which platform.

> (Except perhaps for a basic console app that only does file i/o. But
> then gcc is exactly such an app which apparently took years to make it
> to Windows.)

What you call a "basic console app" could be anything from 'Hello, 
world' to a multi-million-line monster. The word "basic" is misplaced.

> Also because the developer wouldn't be that stupid.

Precisely! Exactly my point! Nobody in their right mind would develop a 
Windows installer with file association functionality for a program 
that's going to be tested on Unix and then flipped up to the mainframe. 
It's completely bloody daft. And when I dared to say that 
file-associating installers aren't always required, I was told I had 
obviously never done systems analysis!

You can't have it both ways. You can't reasonably say that it's always 
necessary to provide installers /and/ that it's sometimes stupid to 
provide them.

-- 
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]

#6852

In article <nnah8t$10j$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> 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.

In other words you're talking about a single-customer single-use 
souurce-code library, not a standalone application.

And you wouldn't provide a makefile with this source code?

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

#6857

On 28/07/16 11:51, J. Clarke wrote:
> In article <nnah8t$10j$1@dont-email.me>, rjh@cpax.org.uk says...
>>
<snip>
>>
>> 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.
>
> In other words you're talking about a single-customer single-use
> souurce-code library, not a standalone application.

What? No! You're missing the whole point of my argument!

I'm talking about the fact that there's more than one use case. For some 
use cases, an installer is very definitely the right way to go. For 
others, it's a waste of time. And it's important to find out which, 
/before/ you write the installer. And the use case can depend just as 
much on the /user/ as it does on the nature of the program.

> And you wouldn't provide a makefile with this source code?

If that's appropriate, yes. But not if it isn't. It depends on the 
circumstances.

-- 
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]

#6846

On Wed, 27 Jul 2016 11:04:34 +0100, BartC wrote:

>On 27/07/2016 08:10, Richard Heathfield wrote:
>> 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.

If I have a choice between a versio with an installer and one in a zip
file that is portable without the cursed "installation" process, the
version in a zip file wins every time.

If I have a choice between Vendor A's program with an installer and
Vendor B's program that meets my need and doesn't afflict me with a
cursed "installation" process, Vendor B wins every time.

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

#6847

"Wally W." wrote:

> On Wed, 27 Jul 2016 11:04:34 +0100, BartC wrote:
>
>>On 27/07/2016 08:10, Richard Heathfield wrote:
>>> 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.
>
> If I have a choice between a versio with an installer and one in a zip
> file that is portable without the cursed "installation" process, the
> version in a zip file wins every time.
>
> If I have a choice between Vendor A's program with an installer and
> Vendor B's program that meets my need and doesn't afflict me with a
> cursed "installation" process, Vendor B wins every time.

I absolutely agree, if there are no more constraints than have been listed 
so far for the ZIP version. One constraint that I am almost certain exists 
is the program vendor can't put the cute Windows icon on his packaging. 
Marketing people associated with the program would create a huge fuss, 
giving µsoft a lot of leverage. 

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

#6848

On 28/07/16 04:37, Osmium wrote:
> One constraint that I am almost
> certain exists is the program vendor can't put the cute Windows icon on
> his packaging.

That hardly matters if it's an OS/2 program, or a MacOS program, or a 
VM/CMS program. In fact, it hardly matters even if it's a Windows 
program. Who gives a toss about the Windows icon?

If the client requires the program to conform with Microsoft's list of 
criteria for badging the packaging in that way, then /that is part of 
the specification/! It should be established in the requirements phase. 
And if it's not part of the spec, why on earth would it matter? But if 
it /is/ part of the spec, then of course all that stuff goes in.

-- 
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]

#6854

In article <nnc8n8$ere$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> On 28/07/16 04:37, Osmium wrote:
> > One constraint that I am almost
> > certain exists is the program vendor can't put the cute Windows icon on
> > his packaging.
> 
> That hardly matters if it's an OS/2 program, or a MacOS program, or a 
> VM/CMS program. In fact, it hardly matters even if it's a Windows 
> program. Who gives a toss about the Windows icon?

Someone who wants to make more money than a bottom tier contract 
programmer makes?
 
> If the client requires the program to conform with Microsoft's list of 
> criteria for badging the packaging in that way, then /that is part of 
> the specification/! It should be established in the requirements phase. 
> And if it's not part of the spec, why on earth would it matter? But if 
> it /is/ part of the spec, then of course all that stuff goes in.

And of course they're going to hire you to single-handedly, by-the-hour 
develop their commercial application.

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

#6853

In article <dvtcvoFccolU1@mid.individual.net>, r124c4u102@comcast.net 
says...
> 
> "Wally W." wrote:
> 
> > On Wed, 27 Jul 2016 11:04:34 +0100, BartC wrote:
> >
> >>On 27/07/2016 08:10, Richard Heathfield wrote:
> >>> 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.
> >
> > If I have a choice between a versio with an installer and one in a zip
> > file that is portable without the cursed "installation" process, the
> > version in a zip file wins every time.
> >
> > If I have a choice between Vendor A's program with an installer and
> > Vendor B's program that meets my need and doesn't afflict me with a
> > cursed "installation" process, Vendor B wins every time.
> 
> I absolutely agree, if there are no more constraints than have been listed 
> so far for the ZIP version. One constraint that I am almost certain exists 
> is the program vendor can't put the cute Windows icon on his packaging. 
> Marketing people associated with the program would create a huge fuss, 
> giving µsoft a lot of leverage. 

If the zip file in fact (a) works and (b) doesn't make changes to the 
registry and other parts of the OS that later have to be researched by 
the person removing the code and undone by hand, that's fine.  But 
Richard strikes me as the sort who couldn't be assed to check his code 
for side effects.

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

#6858

On Thu, 28 Jul 2016 06:53:06 -0400, J. Clarke wrote:

>In article <dvtcvoFccolU1@mid.individual.net>, r124c4u102@comcast.net 
>says...
>> 
>> "Wally W." wrote:
>> 
>> > On Wed, 27 Jul 2016 11:04:34 +0100, BartC wrote:
>> >
>> >>On 27/07/2016 08:10, Richard Heathfield wrote:
>> >>> 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.
>> >
>> > If I have a choice between a versio with an installer and one in a zip
>> > file that is portable without the cursed "installation" process, the
>> > version in a zip file wins every time.
>> >
>> > If I have a choice between Vendor A's program with an installer and
>> > Vendor B's program that meets my need and doesn't afflict me with a
>> > cursed "installation" process, Vendor B wins every time.
>> 
>> I absolutely agree, if there are no more constraints than have been listed 
>> so far for the ZIP version. One constraint that I am almost certain exists 
>> is the program vendor can't put the cute Windows icon on his packaging. 
>> Marketing people associated with the program would create a huge fuss, 
>> giving µsoft a lot of leverage. 
>
>If the zip file in fact (a) works 

... and programs that have installers always work?

>and (b) doesn't make changes to the 
>registry and other parts of the OS that later have to be researched by 
>the person removing the code and undone by hand, that's fine.

Potentially an issue.

Ideally, the program uses an INI file and stays away from my registry.

... it is *my* registry, you know.

>  But 
>Richard strikes me as the sort who couldn't be assed to check his code 
>for side effects.

He seems to be someone I would want on my project more than you do.

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

#6841

On Wednesday, 27 July 2016 10:10:54 UTC+3, 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).
>
> > 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. 

You're in bad mood, that feels unusual hyperbole. Wasn't it done by
student to teacher? What school pays money to students for assignment?
 What money was assumed as asked for installer?  That money is imaginary
here, isn't it?

If we now consider real money on market then aren't the quality of
documentation and support and deployment as seeked after as
are quality and performance of product itself?

Going to other edge of same hyperbole would be to say that no
delivery at all, just "done at my home PC!"  with daft face gets A+
since no imaginary money of no one was "wasted".

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

#6851

In article <nn9mps$69j$1@dont-email.me>, rjh@cpax.org.uk says...
> 
> 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).

Ok, now we understand you completely.  You punish initiative.
 
> > 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.

No, I have control of my billing.
 
> 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.

So who is paying the above mentioned student by the hour?
 
> 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.

You keep going on about "the client".  You seem to think that all 
programmers work by the hour and that all software is single use to be 
thrown away.
 
> 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?

The trouble is that I've had employees with attitudes such as yours.  
And I never want another one.

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

#6856

On 28/07/16 11:48, J. Clarke wrote:
> In article <nn9mps$69j$1@dont-email.me>, rjh@cpax.org.uk says...
>>
>> 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).
>
> Ok, now we understand you completely.  You punish initiative.

And you reward irrelevant distractions from the task at hand. OR we 
could discuss the matter sensibly and intelligently, like grown-ups. Why 
are your responses so aggressive? Isn't it possible to disagree without 
being rude?

>
>>> 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.
>
> No, I have control of my billing.

Fine. And, as a customer, I now know that you're likely to bill me for 
stuff I don't want or need, so I'm going to avoid using your services. 
Of course, that won't bother you, because you have plenty of other 
customers who are prepared to pay for stuff they haven't ordered.

>
>> 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.
>
> So who is paying the above mentioned student by the hour?

That depends on how students are funded in that institution, and it's 
irrelevant to the question at hand.

>
>> 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.
>
> You keep going on about "the client".  You seem to think that all
> programmers work by the hour and that all software is single use to be
> thrown away.

You seem to jump to false conclusions very quickly. I don't think all 
software is single-use. Nor do I think that all programmers work by the 
hour. Nor do I think that all programmers have clients in the sense that 
you are taking it. Some have employers. Some are hobbyists. Some /are/ 
employers. By "client" I only mean the person that foots the bill. That 
might be the programmer himself. Or it might mean the taxpayer. Or it 
might mean people who buy the software off the shelf in a shop. Or it 
might mean an IT department in a large company. The possibilities are 
many and varied, and in /some/ of those scenarios an installation 
program makes sense and in /others/ it doesn't.

>
>> 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?
>
> The trouble is that I've had employees with attitudes such as yours.
> And I never want another one.

<shrug> My attitude is that a good programmer provides what the client 
asks for, and /thinks about/ what the client probably needs but hasn't 
asked for, and then offers it to the client, explaining the impact in 
cost and time. If that's a bad attitude, so be it, but I think it's a 
better attitude than "the programmer is always right".

-- 
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]

#6859

On Thu, 28 Jul 2016 12:21:19 +0100, Richard Heathfield wrote:

>On 28/07/16 11:48, J. Clarke wrote:
>> In article <nn9mps$69j$1@dont-email.me>, rjh@cpax.org.uk says...
>>>
>>> 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).
>>
>> Ok, now we understand you completely.  You punish initiative.
>
>And you reward irrelevant distractions from the task at hand. OR we 
>could discuss the matter sensibly and intelligently, like grown-ups. Why 
>are your responses so aggressive? Isn't it possible to disagree without 
>being rude?
>
>>
>>>> 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.
>>
>> No, I have control of my billing.
>
>Fine. And, as a customer, I now know that you're likely to bill me for 
>stuff I don't want or need, so I'm going to avoid using your services. 
>Of course, that won't bother you, because you have plenty of other 
>customers who are prepared to pay for stuff they haven't ordered.
>
>>
>>> 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.
>>
>> So who is paying the above mentioned student by the hour?
>
>That depends on how students are funded in that institution, and it's 
>irrelevant to the question at hand.
>
>>
>>> 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.
>>
>> You keep going on about "the client".  You seem to think that all
>> programmers work by the hour and that all software is single use to be
>> thrown away.
>
>You seem to jump to false conclusions very quickly. I don't think all 
>software is single-use. Nor do I think that all programmers work by the 
>hour. Nor do I think that all programmers have clients in the sense that 
>you are taking it. Some have employers. Some are hobbyists. Some /are/ 
>employers. By "client" I only mean the person that foots the bill. That 
>might be the programmer himself. Or it might mean the taxpayer. Or it 
>might mean people who buy the software off the shelf in a shop. Or it 
>might mean an IT department in a large company. The possibilities are 
>many and varied, and in /some/ of those scenarios an installation 
>program makes sense and in /others/ it doesn't.
>
>>
>>> 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?
>>
>> The trouble is that I've had employees with attitudes such as yours.
>> And I never want another one.
>
><shrug> My attitude is that a good programmer provides what the client 
>asks for, and /thinks about/ what the client probably needs but hasn't 
>asked for, and then offers it to the client, explaining the impact in 
>cost and time. If that's a bad attitude, so be it, but I think it's a 
>better attitude than "the programmer is always right".

Agreed. The latter is far too common.

Many examples of the latter can be seen on forums where people have
been complaining for years about missing (or removed!) features in
flagship products from (shall we say) a major software vendor. The
latest replies from the mother ship: great idea ... we're thinking
about it.

The latter type who can't do programming might be heard saying, "I am
from the IT department ... and I'm here to help you."

Which means they have come to make *their* job easier, not to actually
be **support** staff.

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

#6860

I'm rather shocked this is such a raging debate over a non-issue.

If you write a specification for a program, it includes *all* of
the deliverables. Period.

If you are the customer (or employer) in such an arrangement, you
put in all features, behaviors, etc. into the spec. that you need
for the project to succeed.

If you are the developer(s) and you see something missing before
the spec is finalized, then by all means bring it up. If nothing
else, it's a good negotiating point when it comes time to talk
schedule and money.

Now back to your regularly scheduled arguments about minutiae.


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#6861

On 28/07/16 22:13, Randy Howard wrote:
>
> I'm rather shocked this is such a raging debate over a non-issue.
>
> If you write a specification for a program, it includes *all* of
> the deliverables. Period.

Uh, precisely.

> Now back to your regularly scheduled arguments about minutiae.


Ta. Now, where were we...
<g,d&r>

-- 
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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.programming

csiph-web