Re: Kiss and say goodbye to Microsoft!!

From: Bill McKenzie (bmckenzie@driver.attbbs.com)
Date: 02/20/02


From: "Bill McKenzie" <bmckenzie@driver.attbbs.com>
Date: Wed, 20 Feb 2002 10:01:39 -0600


> > I wonder if Bill's problem is similar to the one I have - when you make
money
> > selling product, it's easy to justify your income as honourable. You
write
> > stuff that's good enough for people to buy. But when you make money
selling
> > support for a free product, you essentially run into the issue of making
money
> > by producing a product that isn't good enough to operate without
support.
> >
> > As long as I can remain providing free support, and making money only on
sale
> > of product, I won't feel that I'm making people pay for my
shortcomings - in
> > fact, I have a strong incentive to remove bugs from the program before
it's
> > released.
>
> If you're a one-man show, then I guess there is a conflict of interest
> that's painful to manage. Let a good designer/coder team up with a
> good maintainer, though, and it's simply a question of which you
> choose to consider the profit center.
>

No it isn't and that is my point. Service revenue for a small to medium
software shop is difficult to maintain. I can survive as a contractor, but
I sure rather contract and have a good product on the market. That way I
can hedge the times when contracts slow down. Or I can take a day off once
in a while. If your revenue is solely based on service it is difficult to
maintain, and unless you make a buttload of money, its difficult to get away
from the shop. This is true even for some medium sized shops. The coverage
is just generally not there as not all engineers specialize in the same
fields, not all are equal, etc.

> You know, support is not *just* overcoming flaws in a buggy product.
> Some people simply can't be bothered to understand the nuances of a
> powerful product, because they're busy thinking about their own,
> non-computing, business. They'd rather pay you to help them make it
> work because it's cheaper than taking the time to learn how to do it
> right themselves. It's like, I *could* do my own surgery, but it's
> really much better for me to hire someone who already knows how and
> has had lots of practice.
>

If you were a surgeon you could probably perform your own surgery and you
might. I expect technical companies to be able to pick up my product and
perform their task quicker and with better quality. If they have trouble
they can call up and get help for free. If they can't use my product to do
that, then I haven't done my job.

> I don't hear anybody complaining that cars are not good enough to run
> without maintenance

You obviously don't live in my neighborhood. Everybody complains about
cars. That is why Japanese cars stormed the United States a few years back,
because they were about 10x more reliable than those made here. This is a
perfect example of an industry where competitive product pressure brought
about higher quality products.

> Some artifacts are not and cannot be fully
> turn-key. The more powerful they are, the more likely it is that we
> need expert help to begin using them, or to maintain their usability.
> I expect a product to be well-designed and well-executed, and that the
> documentation gives me a reasonable chance of being able to understand
> it, but I also expect to need help sometimes when I use it in a way
> that the designer never thought of.

You will only get a well-designed, well-executed, and well-documented
product if there is an economic reason for someone to deliver that to you.
If the revenue to be made is from support, then there is no reason to
design, to execute reasonably, and there is absolutely no reason to document
anything in even a remotely clear fashion. And in fact there is heavy
economic pressure to do none of these.

> It's dishonest to deliberately release buggy or inadequately-
> documented code in order to inflate service revenue. But it's quite
> honorable to release clean, well-documented code that generates honest
> requirements for expert guidance now and then. Most people don't
> understand your code as well as you do, and that's as it should be,
> because you don't understand the totality of their business as well as
> they do either. I'd be worried if I published something and *never*
> got questions about it.
>

Because something is dishonest doesn't mean people won't do it, especially
if there is economic pressure to do it.
Sad but true.

If I sell my code to a firm specializing in software of a similar nature
they better understand it. But, you are correct, there will be questions.
That is what good documentation is for, and as a last result free tech
support. With the drive to sell products comes the drive to reduce costs.
Tech support takes away from the net revenue on a product. So, you can
handle this in two ways, refuse tech support, then your products won't sell,
or make a product good enough that it requires very little support and only
in special circumstances. That is the beauty of a product based economy.
The economic pressure is to give people get more for less.

> Now, the incentive to do a good job doesn't have to be monetary. It
> really bothers me to find bugs in others' code and I absolutely will
> not tolerate them in my own code. A few slip through anyway, but I'm
> finicky enough to hunt down and kill most of them, or better yet
> design them out at the start. It would take a large pile of money
> indeed to smother the bad feeling I have when someone discovers a flaw
> that I missed in my own work.
>
> --
> Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
> Our lives are forever changed. But *that* is exactly as it always was.

Well, the incentive to do a good job may not have to be monetary for you or
me, but monetary pressure in the marketplace is what drives results. If
people get rewarded for producing lousy code, that is what they will produce
on the whole. And, BTW, looking over the Linux kernel a couple of times
before, it seems that is the result. If you call Linux code on the whole
'good code' I fail to see how you and I can argue anything reasonably.

--
Bill McKenzie
Software Engineer
BSquare Corporation
**Try out our driver tools free for 30-days**
www.bsquare.com/offer/download



Relevant Pages

  • Re: "Forced labour for Jobseekers"
    ... but I do think it is all the more reason to go out and earn money to ... support yourself, instead of becoming dependent on state handouts. ...
    (uk.legal)
  • Re: OpenVMS Support Issues
    ... We can direct that our money be moved elsewhere. ... please not at the engineer and support level. ... they're where my VMS level of knowledge was in 1990 ... Do you not think all logic and reason have not been applied? ...
    (comp.os.vms)
  • Re: : Welcome to lockdown - HP limiting access to patches
    ... HP is in business for one reason and one reason only. ... To make money. ... they had the Hobbyist Program. ... If you wanted any sort of support, "N" levels were available for moderately outrageous fees! ...
    (comp.os.vms)
  • Re: life after Windows....
    ... few do have macs- in addition, the recording studios, composition ... They don't have to make money and their IT support people tend to be very ... You can't reason with someone whose first line of argument is ...
    (rec.travel.europe)
  • Re: disability and divorce settlement
    ... >my point - i deserve support like any other wife in a divorce where her ... Man, Woman, whatever, when you let hate control your actions you ... >> money if you CAN support yourself? ... >i dont think it is wrong to want to have my own home, ...
    (alt.support.mult-sclerosis)