why program to interface is better design?
jrefa...@hotmail.com
1) Transaction t = new BankTransaction();
The following only uses the concrete class without the interface
2) BankTransaction t = new BankTransaction();
Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
same output.
public interface Transaction
{
public void deposit(double amt);
}
public class BankTransaction implements Transaction
{
private double balance = 100;
public void deposit(double amt)
{ balance += amt;
}
}
public class BankTransactionTest
{ public static void main(String[] args)
{ Transaction t = new BankTransaction(); //program to interface??
//BankTransaction t = new BankTransaction();
t.deposit(200);
}
}
Roedy Green
:
>Is this an example of program to interface?
>1) Transaction t = new BankTransaction();
>
>The following only uses the concrete class without the interface
>2) BankTransaction t = new BankTransaction();
>
>
>Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
>same output.
The advantage of using Transaction is you could later change your code
to Transaction t = new CreditUnionTransaction();
and everything would still work.
The code might not work otherwise because you might have inadvertently
used a BankTransaction method needlessly that CreditUnionTransaction
did not have. Sticking to only the basic Transaction methods is a
sort of a voluntary straight jacket to make your code more pluggable.
IIRC I explain the pluggability advantage further at
http://mindprod.com/jgloss/interface.html
or one of the things it links to.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
lqw0205
public interface Transaction{
public void deposit(double amt);
}
//AnotherTransaction.java
public class AnotherTransaction implements Transaction{
private double balance = 100;
public void deposit(double amt){
//Here's different from BankTrasaction
balance -= amt;
System.out.println("AnotherTrasaction.deposit:" + balance);
}
}
//BankTransaction.java
public class BankTransaction implements Transaction{
private double balance = 100;
public void deposit(double amt){
balance += amt;
System.out.println("BankTransaction.deposit:" + balance);
}
}
//BankTransactionTest.java
public class BankTransactionTest{
public static void main(String[] args){
Transaction t1 = new BankTransaction();
Transaction t2 = new AnotherTransaction();
//I don't care about it's a reference of BankTrasaction or
AnotherTrasaction,it works good!
t1.deposit(200); //BankTransaction.deposit:300.0
t2.deposit(200); //AnotherTrasaction.deposit:-100.0
}
}
Andrea Desole
jrefa...@hotmail.com wrote:
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.
the previous posts have explained well enough why 1 can be better than
2. Shortly, an interface gives you more abstraction, and makes the code
more flexible and resilient to changes, because you can use different
implementations of the same interface without changing its client.
Still, if you don't think your code will change, or (specially) if you
think your abstraction is good enough, you don't necessarily have to use
solution 1.
In other words: interfaces are good, but before making an interface for
every class think about it
Laurent Bossavit
> same output.
I'm wondering why you're appending this note about "yield the same
output". Two competing designs *should* produce the same output - if
they don't, then we choose among the alternatives based on what the
output should be. (In other words, "the requirements" - loosely
speaking.)
Output has nothing to do with how you go about selecting among design
alternatives. (Think of it this way - a Big Mac and an escalope cordon
bleu with gratin also produce the same output, after a while. But I know
which one I'd rather have.)
The question, then, is this: what qualities are you interested in, that
may help you choose between 1) and 2) ?
Laurent
Chris Smith
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.
Good question, actually!
There are, of course, any number of situations in which programming to
the interface is quite beneficial... such as, for example:
public void doDeposit(Transaction t, int amount)
{
if (amount > MAX_DEPOSIT) throw new DepositException();
t.deposit(amount);
}
That's nice because you could pass any kind of Transaction and still end
up with the same result. This is reuse of code, avoids duplication, and
I think everyone can agree that it's better design than to write two
different methods where one takes a BankTransaction and the other a
CreditTransaction, if we assume that the requirements being enforced are
the same for both.
In your case, though, you've both created and used a reference within
the same method. Really, it hardly matters in that situation. If
anything, the one slight reason for choosing the interface is just to
develop a habit of using abstraction when it's available to you. But
even that is rather dubious. It makes almost no difference from any
kind of practical perspective that I can see.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Andrea Desole
Laurent Bossavit wrote:
> Output has nothing to do with how you go about selecting among design
> alternatives. (Think of it this way - a Big Mac and an escalope cordon
> bleu with gratin also produce the same output, after a while. But I know
> which one I'd rather have.)
definitely a Big Mac. No, okay, I was not serious.
Besides that, I'm sure some people would just say "well, it's all food".
This is also the mentality some people have when they write software:
"it works, so it's enough". Several times I tried to convince some of
these people that it's not enough. Never been very successful
Laurent Bossavit
> > alternatives. (Think of it this way - a Big Mac and an escalope cordon
> > bleu with gratin also produce the same output, after a while. But I know
> > which one I'd rather have.)
>
> definitely a Big Mac. No, okay, I was not serious.
> Besides that, I'm sure some people would just say "well, it's all food".
Yes, and that's fine. People might think like that.
The fact of the matter is that gourmet food is a huge business, so there
is market value in doing quality work. Similarly I believe there is
market value in software that has internal quality, regardless of how it
behaves externally.
The other fact of the matter is that BigMac food is also a huge
business, so there is market value in churning out identical product at
a known level of intrinsic quality - even if that quality is low
(negative, if you consider health issues).
> This is also the mentality some people have when they write software:
> "it works, so it's enough". Several times I tried to convince some of
> these people that it's not enough. Never been very successful
I've tried a different tack: don't try to convince people, but pick and
choose the people I associate with among those who are already convinced
that it's not enough that the program produces the expected output. Not
quite as easy as it sounds, but it works for me.
Laurent
Thomas G. Marshall
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.
>
> public interface Transaction
The other posts here are enough. However, you should understand that
"program to interface" does not specifically mean java interface.
The term "interface" is an OO concept. If you had, say, language with no
"interface" keyword/construct like java has, then you would still be able to
program to interface, by programming specifically to the highest level
superclass (perhaps abstract) you can that supplies the methods
(interface/functionality) you need.
...[rip]...
Thomas G. Marshall
Sometimes you will have a customer that just wants you to produce just that:
something that works, and will only pay for that much. Forget the lofty
goals of maintainability and reusability. Forget the hoity concepts of
clear headed design. (all sarcasm). The point is, a contractor is often
left without a choice. The same goes for salaried personel under an absurd
deadline. Go in, do it, get out.
Many times people seem to act as if time is never a factor in design. It
almost /always/ is.
Roedy Green
<tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
:
> The point is, a contractor is often
>left without a choice. The same goes for salaried personel under an absurd
>deadline. Go in, do it, get out.
I think we ought to think of ourselves more like dentists. The
patient can say all they want about their wishes, but it is up to you
to interpret them in a way you don't actually harm the patient.
The same applies to architects and boat builders. You have a
professional duty not to build something dangerous even if your idiot
customer asks you to.
Laurent Bossavit
> The point is, a contractor is often left without a choice.
[The choice to do quality work]
I submit that the contractor *has* a choice. Always. And interestingly,
there is an interesting cross-thread connection to the discussion of
software-as-craft. A craftsman is one who *knows* he has that choice.
> The same goes for salaried personel under an absurd deadline. Go in,
> do it, get out.
If the deadline is unrealistic, the project will fail. To agree to do
the project under these conditions is to be complicit in the failure. In
these conditions, we should exercise our choice not to take part in the
project.
Laurent
Ulrich Hobelmann
> On Fri, 30 Sep 2005 01:15:55 GMT, "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
> :
>
>> The point is, a contractor is often
>> left without a choice. The same goes for salaried personel under an absurd
>> deadline. Go in, do it, get out.
>
> I think we ought to think of ourselves more like dentists. The
> patient can say all they want about their wishes, but it is up to you
> to interpret them in a way you don't actually harm the patient.
Yes, a hippomatic OOath would be cool.
> The same applies to architects and boat builders. You have a
> professional duty not to build something dangerous even if your idiot
> customer asks you to.
Problem is, if you say "but we need time for testing, and it costs this
much" then the guy goes to someone else. Nevermind that someone else
can't do the job properly, and that it'll actually cost MORE than you
said you would charge, but the other guy ends up with the money.
In many cases, the customer will even pay the someone else MORE after
missing the deadline. Funny that the contracts don't seem to mention
delivery for fixed price. At least that's what usually happens with
projects initiated by the German government.
--
Do or do not. There is no try.
Yoda
Andrea Desole
Thomas G. Marshall wrote:
>
> Sometimes you will have a customer that just wants you to produce just that:
> something that works, and will only pay for that much. Forget the lofty
> goals of maintainability and reusability. Forget the hoity concepts of
> clear headed design. (all sarcasm). The point is, a contractor is often
> left without a choice. The same goes for salaried personel under an absurd
> deadline. Go in, do it, get out.
I agree with that, and I have to say that sometimes you have something
small to implement, without special enhancements needed later. In that
case you don't have to do fancy things: when the application works, you
are done, and nothing else is needed.
But often this is not the case, and people don't understand that fast,
good and cheap don't go together. If something works now they don't
think about what will happen in one or two years. If you want a long
term project, or worse, a product, this is not the way to proceed. I'm
not against hacking, the first thing is always to get a result. But if
you hack it now, you will have to fix it later, or you are probably not
going to get any more results.
And the worst thing is: when people just don't care, and the situation
gets slowly worse and worse, and people start panicking, guess who is
going to fix it?
By the way: I'm not a contractor, so this is more an employee's point of
view
Roedy Green
<u.hob...@web.de> wrote or quoted :
>In many cases, the customer will even pay the someone else MORE after
>missing the deadline.
There is some saying that goes something like, there is always
time/money/budget to fix a problem but never to prevent it.
It is not just computers. Look at the Katrina costs now that could
have been saved with a little more prevention.
Berislav Lopac
> Output has nothing to do with how you go about selecting among design
> alternatives. (Think of it this way - a Big Mac and an escalope cordon
> bleu with gratin also produce the same output, after a while. But I
> know which one I'd rather have.)
While hilarious, this comparison is totally off-mark. If we compare software
systems to bodily functions, the food in your example has nothing to do with
systems design -- it's just a different kinds of input, one being a giant
Word file with no formatting consistency, hundreds of various fonts,
space-based tables and untested data, and the other being a neat XML format
with a cleanly designed DTD and carefully checked data. The fact that our
system can parse and produce the same output from both (although with some
unwanted side effects in one case) just proves that the system is
well-designed overall.
Berislav
Thomas G. Marshall
This is pedantic silliness.
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" ?
A customer might /need/ a crap project put together in haste.
Anyone who knows me in this newsgroup, and in others, knows the extent to
which I greatly value properly written code. I often painfully describe out
core issues that have been missed by posters in a strong attempt to get them
to understand the issue. But *do* *not* *romanticize* what we are doing: we
are doing a service/product for a customer, and as such, if the customer
/thinks/ he can afford only a sloppy blindingly quickly put-together
project, then stamping your feet and saying "no" is simply childish.
--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."
Thomas G. Marshall
> Thomas G. Marshall wrote:
>>
>> Sometimes you will have a customer that just wants you to produce
>> just that: something that works, and will only pay for that much. Forget
>> the lofty goals of maintainability and reusability. Forget
>> the hoity concepts of clear headed design. (all sarcasm). The point
>> is, a contractor is often left without a choice. The same goes for
>> salaried personel under an absurd deadline. Go in, do it, get out.
>
> I agree with that, and I have to say that sometimes you have something
> small to implement, without special enhancements needed later. In that
> case you don't have to do fancy things: when the application works,
> you are done, and nothing else is needed.
> But often this is not the case, and people don't understand that fast,
> good and cheap don't go together.
Oh absolutely! And sometimes you are just simply not able to get past that:
sometimes their money just isn't there, or they have budgeted just for
something of X quality, where X is far less than what you would normally
consider ideal.
> If something works now they don't
> think about what will happen in one or two years. If you want a long
> term project, or worse, a product, this is not the way to proceed. I'm
> not against hacking, the first thing is always to get a result. But if
> you hack it now, you will have to fix it later, or you are probably
> not going to get any more results.
> And the worst thing is: when people just don't care, and the situation
> gets slowly worse and worse, and people start panicking, guess who is
> going to fix it?
{shrug} Presumably the same person who made it will be /paid/ to fix it.
> By the way: I'm not a contractor, so this is more an employee's point
> of view
--
Laurent Bossavit
> This is pedantic silliness.
Worse to come, I'm afraid. Save yourself the trouble and killfile me
right now, don't read ahead.
> 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" ?
Now *that* would be self-serving arrogance. What the painter probably
means to say is something like, "The extra coat is going to peel off in
a matter of months and you'll have to do it over again, except this time
the scraping will be more of a pain so you'll end up paying more."
(I don't know the first thing about painting, so I'm just pushing the
metaphor, but the thing is - we know that crap software always ends up
costing more and taking longer.)
> A customer might /need/ a crap project put together in haste.
Let's put it this way: I've never come across this situation. I've seen
crap projects that did not have serious consequences - but that was
always because something *worse* happened to the business, so that the
crap project itself became irrelevant. All the other crap projects I've
seen ended up hurting everyone - client and perpetrator, er, I mean
contractor.
I have never, ever seen a situation where a customer said "This can be
quick and dirty", dirty was delivered quick, and the customer clearly
benefited from it. ("Quick and dirty" should not be confused with "Quick
and just enough to be better than nothing", which does work.)
If you have, I'm interested in hearing your story.
> But *do* *not* *romanticize* what we are doing: we
> are doing a service/product for a customer, and as such, if the customer
> /thinks/ he can afford only a sloppy blindingly quickly put-together
> project, then stamping your feet and saying "no" is simply childish.
Yes, and I'm not suggesting we do that. There are at least three things
we can do. One is to find better clients. Another is to overtly agree to
doing a sloppy job, then covertly do a worthwhile job in the same time
and budget. (I've done that and seen it done.) A third is to find out
why the client is in that bind, and figure out alternative solutions. A
fourth is to first educate the client. Etc...
If the customer /thinks/ he can afford a sloppy blindingly quickly put-
together project, then bowing your head and complying is simply not
mature.
Laurent
Thomas G. Marshall
> Thomas,
>
>> This is pedantic silliness.
>
> Worse to come, I'm afraid. Save yourself the trouble and killfile me
> right now, don't read ahead.
Why? I regard your opinions as fairly worthwhile.
>> 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" ?
>
> Now *that* would be self-serving arrogance. What the painter probably
> means to say is something like, "The extra coat is going to peel off
> in a matter of months and you'll have to do it over again, except
> this time the scraping will be more of a pain so you'll end up paying
> more."
Sure. And the customer says "ok". The painter's supposed to refuse to do
it? How is this different that saying: This project is going to work for
now but 1. not be very maintainable, 2. cost you more later, and 3. irk me
no end. If the customer understands this, (taking human safety related
software off the table---that's a anomoly to this discussion) I see no
reason to not do as the customer wants---unless you romanticise this, there
is no moral nor ethical issue here at all.
Nor have you shown me why I should refuse.
...[rip]...
> 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?
> Another is to
> overtly agree to doing a sloppy job,
So you *have* seen a customer ask for that.
> then covertly do a worthwhile
> job in the same time and budget. (I've done that and seen it done.) A
> third is to find out why the client is in that bind, and figure out
> alternative solutions. A fourth is to first educate the client. Etc...
>
> If the customer /thinks/ he can afford a sloppy blindingly quickly
> put- together project, then bowing your head and complying is simply
> not mature.
And that statement is plainly naive.
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!!!!
Again, take the romanticism out of it. There is no reason that you have
stated that you cannot do as a customer (that knows the issues) wants/needs.
--
"Well, ain't this place a geographical oddity!
Two weeks from everywhere!"
Laurent Bossavit
[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
Monique Y. Mudama
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
Roedy Green
<tgm2tothe...@replacetextwithnumber.hotmail.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.
Monique Y. Mudama
> "Monique Y. Mudama" <sp...@bounceswoosh.org> writes:
>>It's almost a truism that the first product, not the best product,
>>is the one that succeeds in the market.
>
> often nowadays?
Did they make a lot of money before they faded into obscurity? More
than their competitors at the time?
Eric Sosman
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.
Oliver Wong
"Laurent Bossavit" <lau...@dontspambossavit.com> wrote in message
news:MPG.1da7aa707...@news.noos.fr...
> 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
Thomas G. Marshall
> ["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.
Thomas G. Marshall
LOL. Point. Which is why I responded (in comp.object) that there is a time
frame required for the statement to be complete.
Ulrich Hobelmann
> It's almost a truism that the first product, not the best product, is
> the one that succeeds in the market.
Absolutely not. The mac lost to Windows 3.0 and later products. The
German D2 cellphone service (now Vodafone) AFAIK lost its huge market
lead to T-Mobile. I'm sure there are more examples. It's power that
pushes the market, not being the first.
Thomas G. Marshall
Yes, yes. But this is all to the side of the real issue.
The issue as I presented has to do with time-to-market. Time-to-market can
often be the most important concern, whether you are the first videotape
machine, the 5th videotape machine or the last buggywhip.
There is almost always a "race" to market of some kind going on, most
particularly with startups, which live and die by the merest of
thresholds...
--
Doesn't /anyone/ know where I can find a credit card company that
emails me the minute something is charged to my account?
Roedy Green
<tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
:
>There is almost always a "race" to market of some kind going on, most
>particularly with startups, which live and die by the merest of
>thresholds...
People seem to think that writing crappy code will get you finished
faster. I think that is rarely the case. The firmer your foundation,
the faster you can build the house.
Andrew Thompson
> On Sat, 01 Oct 2005 03:17:25 GMT, "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
> :
>
>>There is almost always a "race" to market of some kind going on, most
>>particularly with startups, which live and die by the merest of
>>thresholds...
>
> People seem to think that writing crappy code will get you finished
> faster. I think that is rarely the case. The firmer your foundation,
> the faster you can build the house.
By pushing the 'beta' to market you (the deployer) can..
- Save money on testing by getting the end user to do the
bulk of it for you, and..
- Start making money on 'updates' sooner..
This seems to be the strategy of a particular OS
maker that is currently dominant in the market.
Roedy Green
<seemy...@www.invalid> wrote or quoted :
>By pushing the 'beta' to market you (the deployer) can..
>- Save money on testing by getting the end user to do the
> bulk of it for you, and..
>- Start making money on 'updates' sooner..
Not doing your testing is a separate issue from writing crappy code.
By crappy I mainly mean "unmaintainable". By "unmaintainable' I mean
all the tricks people use to make code hard to change. See
http://mindprod.com/jgloss/unmain.html
Tor Iver Wilhelmsen
> Did they make a lot of money before they faded into obscurity? More
> than their competitors at the time?
Yes, but then they would be the *first* to succeed in the market, not
the *only*. And it's a no-brainer that the first have a better success
than their non-existing (or niche market) competitors.
Tor Iver Wilhelmsen
> LOL. Point. Which is why I responded (in comp.object) that there is a time
> frame required for the statement to be complete.
Yes but that's to trick with numbers. If you had a stock that rose
rapidly for five days before plummeting like a rock, if you restricted
your reporting to those five days you could claim that the stock had a
steady increase in value - but the whole story paints a different
picture.
Donald Roby
> ["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.
>
Why isn't Wordstar the predominant word processor? Or at least WordPerfect?
The product that succeeds is frequently neither best nor first.
Thomas G. Marshall
And there /is/ no "whole story" either. Until the company is out of
business.
--
Having a dog that is a purebred does not qualify it for breeding. Dogs
need to have several generations of clearances for various illnesses
before being bred. If you are breeding dogs without taking care as to
the genetic quality of the dog (again, being purebred is *not* enough),
you are what is known as a "backyard breeder" and are part of the
problem. Most of the congenital problems of present day dogs are
traceable directly to backyard breeding. Spay or neuter your pet
responsibly, and don't just think that you're somehow the exception and
can breed a dog without taking the care described.
Thomas G. Marshall
> On Sat, 01 Oct 2005 03:17:25 GMT, "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
>>
>
>> There is almost always a "race" to market of some kind going on, most
>> particularly with startups, which live and die by the merest of
>> thresholds...
>
> People seem to think that writing crappy code will get you finished
> faster. I think that is rarely the case. The firmer your foundation,
> the faster you can build the house.
Totally incorrect.
The firmer your foundation, the more *solidly* you can build your house.
You can build in no time if you don't do the extensive design. If you're
gonna try to argue against the time-to-market speedup, you're gonna have to
pick a metaphor that /doesn't/ make my argument for me. ;)
Thomas G. Marshall
Succeeds /when/? Word perfect /did/ dominate at one point. So did
"visicalc". In fact, so did "quicken". Things are fluid. This
sub-argument has to end because it has nothing to do with why time-to-market
can be so important in the first place, which was a fundamental component to
my argument.
Roedy Green
<tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
:
>
>The firmer your foundation, the more *solidly* you can build your house.
>You can build in no time if you don't do the extensive design. If you're
>gonna try to argue against the time-to-market speedup, you're gonna have to
>pick a metaphor that /doesn't/ make my argument for me. ;)
Perhaps my house metaphor is off, but quick and dirty nearly always
takes longer to finish, than doing things properly.
Doing things right the first time in almost always fastest to finish,
even if crappy can show SOMETHING sooner.
There was some famous guy who said major projects should be rewritten
from scratch three times, each time learning from the previous one.
Thomas G. Marshall
> On Mon, 03 Oct 2005 03:03:57 GMT, "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
>>
>
>>
>> The firmer your foundation, the more *solidly* you can build your
>> house. You can build in no time if you don't do the extensive
>> design. If you're gonna try to argue against the time-to-market
>> speedup, you're gonna have to pick a metaphor that /doesn't/ make my
>> argument for me. ;)
>
> Perhaps my house metaphor is off, but quick and dirty nearly always
> takes longer to finish, than doing things properly.
>
> Doing things right the first time in almost always fastest to finish,
> even if crappy can show SOMETHING sooner.
>
> There was some famous guy who said major projects should be rewritten
> from scratch three times, each time learning from the previous one.
Well, again, you're confusing overall quality with time to completion. And
to boot, you've mixed in maintainability into this elsethread. Writing code
very quickly is just that: writing it quickly. You don't /try/ to write
crap, and no one /asks/ you to write crap. Crap is a distinct possibility,
but if it works "well enough" in the short term, it will have satisfied the
requirements. So in other words, "doing it quickly" is always faster than
"doing it slowly", by definition. You're confusing the qualifiers.
raxit...@gmail.com
=====================
Hi...use of interface is best in following case.
"For Client Service is important But not Server( which provide
Service)"
Interface is mapped to Service...
Implementation is mpped to Servers....
When in systems you want same Services provided by several different
entities(Servers) use of Interface would SAVE your time/Resources to
change the Servers...
(change of Server's Effect would not propogate to Entire System ...)
Because with interface you are ABSTRACTING Servers...and you can change
servers by maintaining Contract of Service (i.e. Interface)....
Regards
Raxit Sheth
raxit...@gmail.com
Zorro
> professional duty not to build something dangerous even if your idiot
> customer asks you to.
> Problem is, if you say "but we need time for testing, and it costs this
> much" then the guy goes to someone else. Nevermind that someone else
> can't do the job properly, and that it'll actually cost MORE than you
> said you would charge, but the other guy ends up with the money.
This is a true story. I lost a job for refusing to do what would damage
the company. I cannot expose the details of the work. I went through a
lot of hardship, but as I heard, the loss on company was larger. Still,
they thought their programmers could not do it. I will only mention
that my boss was an average IT, with no software development
experience. Yet, he reprted to the CEO!
I never changed, and I have had a very rough life. Those who messed
things up, including the contractor, got pretty good checks.
Interestingly, it was that memory that resulted in my latest blogger on
outsourcing.
Regards,
zor...@ZHMicro.com
http://www.zhmicro.com
http://distributed-software.blogspot.com
http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
Andrea Desole
Thomas G. Marshall wrote:
>
> {shrug} Presumably the same person who made it will be /paid/ to fix it.
Maybe I should start contracting :-)
To my experience it's just the first nice guy who can do the job,
usually with little time. And if it's terribly hacked to make it work,
it doesn't matter, it just has to work. As usual.
Cristiano Sadun
that first avoids the toothing pains which are most visible to the
final customer.
Monique Y. Mudama
>
> Succeeds /when/? Word perfect /did/ dominate at one point. So did
> "visicalc". In fact, so did "quicken". Things are fluid. This
> sub-argument has to end because it has nothing to do with why
> time-to-market can be so important in the first place, which was a
> fundamental component to my argument.
I miss the glory days of WordPerfect. Mmmmm reveal codes.
Thomas G. Marshall
>> The same applies to architects and boat builders. You have a
>> professional duty not to build something dangerous even if your idiot
>> customer asks you to.
>
>
>> Problem is, if you say "but we need time for testing, and it costs
>> this much" then the guy goes to someone else. Nevermind that
>> someone else can't do the job properly, and that it'll actually cost
>> MORE than you said you would charge, but the other guy ends up with
>> the money.
>
> This is a true story. I lost a job for refusing to do what would
> damage the company. I cannot expose the details of the work. I went
> through a lot of hardship, but as I heard, the loss on company was
> larger. Still, they thought their programmers could not do it. I will
> only mention that my boss was an average IT, with no software
> development experience. Yet, he reprted to the CEO!
>
> I never changed, and I have had a very rough life.
Standing on principal can often be very tough. I simply have examined what
I do as simply not worth such principal at all. To do so IMO is to
romanticize the industry, which is silly. Yet I greatly respect your
stance, in that I respect anyone who has guts to stand up, sometimes
entirely irrespective of their opinion.
Interestingly, I am the one who is known for "going to the mat" in arguments
over seeming minutiae. I internally demand perfection, but that's if it is
affordable. Other than that, it's all business calculus. Stop the
ridiculous romance, make your money, be the world's best designer but when
someone's paying you for it.
> Those who messed
> things up, including the contractor, got pretty good checks.
> Interestingly, it was that memory that resulted in my latest blogger
> on outsourcing.
>
> Regards,
> zor...@ZHMicro.com
> http://www.zhmicro.com
> http://distributed-software.blogspot.com
> http://groups-beta.google.com/group/computerlangZ?lnk=la&hl=en
--
Enough is enough. It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet. Newsgroups are
for discussions. Discussions do /not/ necessitate prior research. If
you are bothered by someone asking a question without taking time to
look something up, simply do not respond.
Thomas G. Marshall
>>
>> Succeeds /when/? Word perfect /did/ dominate at one point. So did
>> "visicalc". In fact, so did "quicken". Things are fluid. This
>> sub-argument has to end because it has nothing to do with why
>> time-to-market can be so important in the first place, which was a
>> fundamental component to my argument.
>
> I miss the glory days of WordPerfect. Mmmmm reveal codes.
Oh Christ. That app was a mess. Reminded me of that silly "Gold" key on
VT-52's on WPS-8 word processing software on PDP-8's. Dating myself
terribly. But everything was a bizarre key combinations. Gold-this,
Gold-that. Perhaps only emacs was worse....
Monique Y. Mudama
> Monique Y. Mudama coughed up:
>> On 2005-10-03, Thomas G. Marshall penned:
>>>
>>> Succeeds /when/? Word perfect /did/ dominate at one point. So
>>> did "visicalc". In fact, so did "quicken". Things are fluid.
>>> This sub-argument has to end because it has nothing to do with why
>>> time-to-market can be so important in the first place, which was a
>>> fundamental component to my argument.
>>
>> I miss the glory days of WordPerfect. Mmmmm reveal codes.
>
> Oh Christ. That app was a mess. Reminded me of that silly "Gold"
> key on VT-52's on WPS-8 word processing software on PDP-8's. Dating
> myself terribly. But everything was a bizarre key combinations.
> Gold-this, Gold-that. Perhaps only emacs was worse....
>
No idea what you're talking about. But WP was extremely powerful.
That's worth a bit of extra memorization.
Granted, I'm a vim person, not an emacs person ... I'd rather use home
row keys than control ...
Monique Y. Mudama
2005-10-03, Thomas G. Marshall penned:
>
> arguments over seeming minutiae. I internally demand perfection,
> but that's if it is affordable. Other than that, it's all business
> calculus. Stop the ridiculous romance, make your money, be the
> world's best designer but when someone's paying you for it.
>
When I see a design, maintenance, etc. concern, I do my level best to
bring it to the attention of my lead and make sure they understand the
problem. Once they understand it, it is their job to decide whether
it's a problem worth pursuing.
If I were in more of a leadership role, of course, I would be the one
making such decisions.
Thomas G. Marshall
> On 2005-10-03, Thomas G. Marshall penned:
>> Monique Y. Mudama coughed up:
...[rip]...
>>> I miss the glory days of WordPerfect. Mmmmm reveal codes.
>>
>> Oh Christ. That app was a mess. Reminded me of that silly "Gold"
>> key on VT-52's on WPS-8 word processing software on PDP-8's. Dating
>> myself terribly. But everything was a bizarre key combinations.
>> Gold-this, Gold-that. Perhaps only emacs was worse....
>
> No idea what you're talking about. But WP was extremely powerful.
> That's worth a bit of extra memorization.
>
> Granted, I'm a vim person, not an emacs person ... I'd rather use home
> row keys than control ...
Gotcha. When I ran a unix development department, vi was all I *could* use,
since I couldn't easily get anything else to run on the myriad of
pre-released hardware I had to port to. Used (use) VI for years. Use it
now, for when I cygwin-BASH {shudder} into a directory for bare-knuckles
editing/javac/java cycling.
--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.
Tor Iver Wilhelmsen
> I miss the glory days of WordPerfect. Mmmmm reveal codes.
*Reveal* them? They should be in the document all the time. Wordstar
and TROFF for the win.
Zorro
> bring it to the attention of my lead and make sure they understand the
> problem. Once they understand it, it is their job to decide whether
> it's a problem worth pursuing.
> If I were in more of a leadership role, of course, I would be the one
> making such decisions.
What you are saying in correct. In fact, just about any meaningful
statement is correct in some context. Of course your statement is not
just a meaningful one, it is a proper procedure and under normal
circumstances, that is how one should proceed.
I do not know if this will benefit anyone, but with the hope that it
may result in positive and constructive reactions, I will give a little
more detail of the incident. The point is that, an engineer who knows
what he is doing, should not just do what he is told to.
I was maintaining a C++ library of over 120,000 lines, with a huge
number of classes. The CEO really wanted to replace our competitor's
library with ours for a customer. This is a reasonable suggestion. The
people who talked to him were my boss and the contractor. They told
him, no problem, in fact it is easy.
So, they come to me and tell me how to do it. The contractor wants me
to create a header file containing C macro defines. These defines will
replace every class, method etc of the competitor's library with ours,
in the customer's code.
They seemed to understand my academic explanation about the absurdity
of their suggestion. But my boss insisted that I do it anyway. Then, I
asked them, why do you think the customer would accept this for
probably millions of lines of their code, even if it works. The answer
was, that comes later.
Now, according to your statement, I should have done it anyway. I
explained it, they understood, and the conditions of your statement are
met. There was one problem. My boss could not go back to the CEO and
tell him that he had no clue what he was talking about, and the
contractor was already working on going to customer site to help them
with conversion.
I do not know how this will help. I certainly would not go to the CEO
and speak against my boss. Perhaps it will help the bosses reading this
to learn to talk to their engineer before making promises to their
superiors.
Regards,
Z.
Monique Y. Mudama
>
> Now, according to your statement, I should have done it anyway. I
> explained it, they understood, and the conditions of your statement
> are met. There was one problem. My boss could not go back to the CEO
> and tell him that he had no clue what he was talking about, and the
> contractor was already working on going to customer site to help
> them with conversion.
>
> I do not know how this will help. I certainly would not go to the
> CEO and speak against my boss. Perhaps it will help the bosses
> reading this to learn to talk to their engineer before making
> promises to their superiors.
>
It sounds like the real problem you had was a boss with no integrity.
Of course he could go back to the CEO and admit he was wrong. And in
a good company, being wrong occasionally doesn't get you fired.
I can't see quitting over a technical disagreement, but I can
definitely see quitting because your boss has no spine.
Roedy Green
<tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
:
>Interestingly, I am the one who is known for "going to the mat" in arguments
>over seeming minutiae.
I still sometimes wake up in as sweat thinking about a job I had circa
1993 in toxic company. Life is so short. You would not believe how
fast you get old.
I would suggest to anyone in such a situation, GET OUT. You are
needlessly torturing yourself.
There was a period in my life I had so little money I went without
food and heat I lived on pancakes.. In retrospect, that was much
easier to bear.
David Kerber
sp...@bounceswoosh.org says...
...
> It's almost a truism that the first product, not the best product, is
> the one that succeeds in the market.
And a false one at that. I can't recall a single case where that has
happened, though there must be some. IME, it's usually the 2nd or 3rd
one to market who makes it big, because they learn from the mistakes of
#1, and #1 has let the potential audience know that there's something
out there which might be worth buying. Look at IBM with the PC, Henry
Ford with automobiles, Apple, etc.
--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
Monique Y. Mudama
> In article <slrndjr3h...@home.bounceswoosh.org>,
> sp...@bounceswoosh.org says...
>
> ...
>
>> It's almost a truism that the first product, not the best product,
>> is the one that succeeds in the market.
>
> And a false one at that. I can't recall a single case where that
> has happened, though there must be some. IME, it's usually the 2nd
> or 3rd one to market who makes it big, because they learn from the
> mistakes of #1, and #1 has let the potential audience know that
> there's something out there which might be worth buying. Look at
> IBM with the PC, Henry Ford with automobiles, Apple, etc.
Well, there's a very recent example for my company where a customer
chose another vendor for a product. Our people pointed out that the
competitor's product didn't work as advertised and didn't do what it
promised to do. Their response? "Yes, but theirs is available now."
Ours was still in development.
Certainly lack of a product results in lost business opportunities.
Thomas G. Marshall
Which is why I keep harping on two issues regarding this particular
sub-sub-thread. 1. You need a time frame before you can judge something.
All first-time products have a lock on the industry at one point or another.
2. The need for getting to market quickly is not proven nor disproven by the
likelihood of a first to market product being "the one" that succeeds the
most.
--
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....
Monique Y. Mudama
What you said.
Now I'm regretting my "truism" statement.
Mike Schilling
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
message news:bqb4k1lquglp7f8i8...@4ax.com...
> On Mon, 03 Oct 2005 16:27:41 GMT, "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote or quoted
> :
>
>>Interestingly, I am the one who is known for "going to the mat" in
>>arguments
>>over seeming minutiae.
>
> I still sometimes wake up in as sweat thinking about a job I had circa
> 1993 in toxic company. Life is so short. You would not believe how
> fast you get old.
>
> I would suggest to anyone in such a situation, GET OUT. You are
> needlessly torturing yourself.
>
> There was a period in my life I had so little money I went without
> food and heat I lived on pancakes.. In retrospect, that was much
> easier to bear.
>
I had problems with my neck for about three months once; it got so stiff
that it hurt to turn my head; even driving was painful. I tried sleeping
with no pillow, massage, acupuncture, muscle relaxants, etc. etc. All to no
avail.
The pain went away the day I quit my job.
Chris Uppal
> Roedy Green <my_email_is_post...@munged.invalid> writes:
> > There was a period in my life I had so little money I went without
> > food and heat I lived on pancakes..
>
> I am not a native English speaker, but would consider
> "pancakes" to /be/ food. So possibly, one might say "without
> other food than pancakes".
No, no! You have misunderstood Roedy; he meant quite literally that he lived
on pancakes.
As you may know Canada (and the Northern part of the US) produce large numbers
of pancakes every day, and there is inevitably some considerable
overproduction. North American pancakes (which are thicker than the thin
crepe-like pancakes we know in England[*]) make adequate bedding if you lack
anything better, and surplus pancakes are distributed to the needy by several
charities. Whether you are homeless or "merely" unable to afford to furnish a
living place, a good layer of pancakes can make a hard life just a little
better.
-- chris
([*] I can't forbear adding that English pancakes are nevertheless far
tastier.)
Roedy Green
or quoted :
> I am not a native English speaker, but would consider
> "pancakes" to /be/ food. So possibly, one might say "without
> other food than pancakes".
That is correct. But I think it would take a non-English speaker to
notice the error.
Roedy Green
or quoted :
>>There was a period in my life I had so little money I went without
>>food and heat I lived on pancakes..
>
> I am not a native English speaker, but would consider
> "pancakes" to /be/ food. So possibly, one might say "without
> other food than pancakes".
Explaining this to HAL, I would say. I had so little money I could
not afford to buy food or heat. So I bought neither. However, I had a
supply of various flours, so I survived by making pancakes from them.
For heat I bundled myself in a sleeping bag.
Such times are ever so much more fun to enjoy in retrospect.
Luc The Perverse
> On 10 Oct 2005 11:36:13 GMT, r...@zedat.fu-berlin.de (Stefan Ram) wrote
> or quoted :
>
>>>There was a period in my life I had so little money I went without
>>>food and heat I lived on pancakes..
>>
>> I am not a native English speaker, but would consider
>> "pancakes" to /be/ food. So possibly, one might say "without
>> other food than pancakes".
>
> Explaining this to HAL, I would say. I had so little money I could
> not afford to buy food or heat. So I bought neither. However, I had a
> supply of various flours, so I survived by making pancakes from them.
> For heat I bundled myself in a sleeping bag.
>
> Such times are ever so much more fun to enjoy in retrospect.
~I~ would not have noticed the error.
But Roedy's way is the most elegant.
--
"It's better to have rocked and lost than never to have rocked at
all." -John Flansburgh