«

Thomas,

[Case where the painter warns, "You're going to regret the quick job."]

> Sure. And the customer says "ok". The painter's supposed to refuse to do
> it? unless you romanticise this, there is no moral nor ethical issue here
> at all.

In my view this is not about morals or ethics, as in "the contractor
Ought To refuse the job".

What I'm pointing out is that the contractor is *free* not to accept the
job, i.e. nothing immediately fatal will happen to him if he doesn't
take on the job. Are we agreed on that, or does that deserve more
discussion ?

It follows, if the contractor's choice is free, that he *prefers* to
work on a crap project (for the money, or out of sincere desire to help
the customer) than to do quality work. But then the contractor cannot
later invoke the excuse that "I had no choice about accepting the job".
He must take full responsibility for whatever negative outcomes he *or
the client* might suffer.

Now, I've also pointed out that in all cases I can remember, choosing to
do crap work turned out to hurt everyone. (Perhaps you have different
experiences, if so let's discuss a concrete case.)

So, I've decided to act in my best interest from now on and not turn out
anything less than the best I know. That's in the domains of software
and consulting - in other domains, where I have no professional status,
I behave differently.

> > Yes, and I'm not suggesting we do that. There are at least three
> > things we can do. One is to find better clients.
>
> Again: why? There is a waste deep moral implication in your words that you
> do not elaborate on. This is a service. Go back to the painter. Why *not*
> produce the product that the customer needs at the time?

Why not indeed. My point is that the customer never *needs* crap. He
needs work appropriate to his immediate and longer-term objectives, and
if you're able to deliver it, that's quality work.

> Have you ever seen a customer in a startup situation that needs to get a
> product that works to market as incredibly soon as possible? I have.

I've been in my share of startups. Do you recall any instance where crap
was produced to get something to market first, *and* the startup didn't
tank later ?

The most recent occasion this happened to me (five years ago), I told my
employer "You'll have something in a month. It'll be the best work I can
do. It may be fewer lines of code, or less functionality, than I could
do flat-out, but it'll work and it'll be maintainable, and we can build
additional features on top of that safely."

They took the deal, and they got the money that getting something out
the door quick was supposed to help them make. Everybody won, that first
round. Later on, things got dicey and ultimately the business tanked.
Just a story - but a true story.

> Repeatedly. In this case, the emphasis is getting the damn thing out the
> door. Often that bites the customer hard, but sometimes that only bites the
> customer later. Sometimes getting the thing to market regardless of the
> internal invisible quality of the code is the only way he can get his
> company to the next stage!!!!

In many of these cases, you can still get away with getting quality code
to market fast. You may get less of it to market - but what counts is
not quantity, what counts is showing up. "Getting the company to the
next stage" often involves funding - it's the people with the funding
who're looking at you, not the market, and what they're looking for is
your capacity to deliver on your own promises. If you make no overblown
promises, *and* you have a credible business case, you'll get high marks
there. If your business case *depends* on making overblown promises you
have no business building a business.

Laurent

["Followup-To:" header set to comp.lang.java.programmer.] On
2005-09-30, Thomas G. Marshall penned:
>
> Have you ever seen a customer in a startup situation that needs to
> get a product that works to market as incredibly soon as possible?
> I have. Repeatedly. In this case, the emphasis is getting the damn
> thing out the door. Often that bites the customer hard, but
> sometimes that only bites the customer later. Sometimes getting the
> thing to market regardless of the internal invisible quality of the
> code is the only way he can get his company to the next stage!!!!
>

It's almost a truism that the first product, not the best product, is
the one that succeeds in the market.

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

"Monique Y. Mudama" <> writes:
>It's almost a truism that the first product, not the best
>product, is the one that succeeds in the market.

The first product? That's why we use Visicalc and
Wordstar so often nowadays?

On Fri, 30 Sep 2005 17:33:44 GMT, "Thomas G. Marshall"
<. com> wrote or quoted
:

>If someone wants a painter to paint their house, but only do a quick single
>coat, because they cannot afford to scrape, prime and dual coat it, is the
>painter supposed to say "no no, that is not up to what I'm normally able to
>do" ?

It depends on whether you consider yourself a painter or an architect.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

On 2005-09-30, Stefan Ram penned:
> "Monique Y. Mudama" <> writes:
>>It's almost a truism that the first product, not the best product,
>>is the one that succeeds in the market.
>
> The first product? That's why we use Visicalc and Wordstar so
> often nowadays?

Did they make a lot of money before they faded into obscurity? More
than their competitors at the time?

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

"Monique Y. Mudama" <> writes:
>>>It's almost a truism that the first product, not the best product,
>>>is the one that succeeds in the market.
>>The first product? That's why we use Visicalc and Wordstar so
>>often nowadays?
>Did they make a lot of money before they faded into obscurity? More
>than their competitors at the time?

I do not know how much money they made.

The claim I responded to was "product success", which is not
neccessarily the same as "money made", but open to definition.

Because there are also costs involved, selling many items of a
famous product, does not neccessarily mean to make a lot of
money. Then, the money made might not be evenly distributed
between all the product inventors and persons involved, so the
product might mean "money" only to some of them and "no money"
to others.

Monique Y. Mudama wrote On 09/30/05 15:13,:
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2005-09-30, Thomas G. Marshall penned:
>
>>Have you ever seen a customer in a startup situation that needs to
>>get a product that works to market as incredibly soon as possible?
>>I have. Repeatedly. In this case, the emphasis is getting the damn
>>thing out the door. Often that bites the customer hard, but
>>sometimes that only bites the customer later. Sometimes getting the
>>thing to market regardless of the internal invisible quality of the
>>code is the only way he can get his company to the next stage!!!!
>
> It's almost a truism that the first product, not the best product, is
> the one that succeeds in the market.

That's why Betamax won out over VHS, and why Internet
Explorer never made any headway against Netscape, and why
Google couldn't take market share from AltaVista.

--

"Laurent Bossavit" <> wrote in message
news:...
> I've been in my share of startups. Do you recall any instance where crap
> was produced to get something to market first, *and* the startup didn't
> tank later ?

[ Insert Microsoft Windows joke here. ]

> They took the deal, and they got the money that getting something out
> the door quick was supposed to help them make. Everybody won, that first
> round. Later on, things got dicey and ultimately the business tanked.
> Just a story - but a true story.

"The business tanking" and "everybody winning" are not mutually
exclusive. A bunch of shareholders get together, and put money in to fund a
business. The business produces a mediocre product, but is the first to
market, so people buy the product. The shareholders make a lot of money. A
dozen new companies pop up copying the product, but making it better. The
shareholders pull out of the business, keeping all the money they made. The
business tanks. Everybody wins.

> In many of these cases, you can still get away with getting quality code
> to market fast. You may get less of it to market - but what counts is
> not quantity, what counts is showing up. "Getting the company to the
> next stage" often involves funding - it's the people with the funding
> who're looking at you, not the market, and what they're looking for is
> your capacity to deliver on your own promises. If you make no overblown
> promises, *and* you have a credible business case, you'll get high marks
> there. If your business case *depends* on making overblown promises you
> have no business building a business.

In my experience, the funding people are merely indirectly concerned
with you, the coder, and your business case. The more direct concern is
"We're putting money into this. How much money are we gonna get out of it?"
And that answer may very well depend on the market, and not on whether the
coder can deliver on his/her promises or not (assuming that promise is not,
of course "I'm going to make you all rich.")

- Oliver

Monique Y. Mudama coughed up:
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2005-09-30, Thomas G. Marshall penned:
>>
>> Have you ever seen a customer in a startup situation that needs to
>> get a product that works to market as incredibly soon as possible?
>> I have. Repeatedly. In this case, the emphasis is getting the damn
>> thing out the door. Often that bites the customer hard, but
>> sometimes that only bites the customer later. Sometimes getting the
>> thing to market regardless of the internal invisible quality of the
>> code is the only way he can get his company to the next stage!!!!
>>
>
> It's almost a truism that the first product, not the best product, is
> the one that succeeds in the market.

Bingo. Of course this requires a time frame to be complete. Succeeds
within the first year, 2nd year, after 10 years of course. But in any case
it is still the case that delivery to the market (regardless of coding
quality) can so very often be what is paramount.


--
With knowledge comes sorrow.

Eric Sosman coughed up:
> Monique Y. Mudama wrote On 09/30/05 15:13,:
>> ["Followup-To:" header set to comp.lang.java.programmer.] On
>> 2005-09-30, Thomas G. Marshall penned:
>>
>>> Have you ever seen a customer in a startup situation that needs to
>>> get a product that works to market as incredibly soon as possible?
>>> I have. Repeatedly. In this case, the emphasis is getting the damn
>>> thing out the door. Often that bites the customer hard, but
>>> sometimes that only bites the customer later. Sometimes getting the
>>> thing to market regardless of the internal invisible quality of the
>>> code is the only way he can get his company to the next stage!!!!
>>
>> It's almost a truism that the first product, not the best product, is
>> the one that succeeds in the market.
>
> That's why Betamax won out over VHS, and why Internet
> Explorer never made any headway against Netscape, and why
> Google couldn't take market share from AltaVista.

LOL. Point. Which is why I responded (in comp.object) that there is a time
frame required for the statement to be complete.

--
With knowledge comes sorrow.