Re: Larkin, Power BASIC cannot be THAT good:

On Fri, 12 Jun 2009 08:58:43 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:
On Thu, 11 Jun 2009 09:31:38 +0100, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

John Larkin wrote:

Yes. And management should be able to force software quality, but
usually can't.

You are confusing "excellence" with quality here.

Sigh. I suppose "quality" now means that you can ship it and charge
for it and expect thjat it won't crash too bery often and that your
customers will find the remaining hundreds of crashes and security
vulnerabilities by experiment.

There are a couple of reasonable responses to this: use simpler,
preferably free, stuff that does the basic job; and if your PC works
and is finally mostly stable, don't upgrade.


If they did not produce a product with *adequate* quality then customers
would not buy it and the company would not make a profit. Microsoft must
be doing something right since the suckers are all buying Office 2007.

So where are the class-action lawyers when we really need tham?


Big company management often pay only lip service to software quality -
it is all about maximising their bonuses which usually means minimum
time to market and maximum immediate sales. Turnover in the sales staff
at software development companies means they are seldom around when the
impossible promises they made to the customer have to be delivered.

Management know full well when the first version ships that is it
riddled with bugs. XL2007 is a good recent example. You can always issue
updates that ameliorate the problems later. But a *new* version is it.
Once customers have it you can persuade other people to upgrade by
making the new file format incompatible with previous versions.

There's another interesting graph: X axis is how hard (or expensive)
it is to change a product in the field, and Y axis is bug density.

The curve dives down. Serious hardware and software designs that are
hard to update (like hard asics, auto engine control computers, or the
stuff inside flat-screen TVs, or military bear) are debugged pretty
hard before being shipped. Mediun things (fpga's, prodcuts that are
easily upgraded with a flash stick) are in-between, Stuff that gets
weekly updates over the web are often horrible.

But that is pure market economics. If it is cheap to fix in the field
then it ships earlier and the company banks the cash. The CEOs duty is
to maximise shareholder value and his own bonus (sometimes mostly the
latter). CPU designs are even more carefully checked and simulated
before they go into production on a fab line. It all depends on the
upfront capital costs to manufacture and the cost of fixing in the
field. You may not like it, but when the in service fix is almost free
to the supplier then they will exploit that to their advantage.

The company managements job is to find the line between a perfect
product delivered too late to make any money at one extreme and a buggy
one that fails to sell because it doesn't work.

Well, I just think that the tradeoff could be shifted a lot in the
quality direction, without extra expense, and with *sooner*
deliveries, with different methods and culture. I don't think that
security vulns are a marketing tool, especially when everybody now
expects that the next release will be just as bad.

The world has suffered mightily from the personality defects of Bill
Gates.


I see this in my own work: hardware designs are checked exhaustively,
and we go out for a batch of expensive multilayer boards (we dom't
prototype!) and they are usually right. Assembly programming, I'm
pretty careful because the assemble-install-test loop is tedious.
On-screen programming is pretty much type and ignite and see what
happens.

You should probably acquire some better in circuit debugging tools then.
Post mortem and realtime debuggers have advanced a long way. Even the
humble PICs have advanced and cheap debuggers available these days. Bugs
are always cheaper to fix the sooner they are caught so it makes sense
to use the best tools available for the job.

My embedded stuff works just fine. Things get done quickly and ship
bug-free, because I'm careful.


Type and ignite has never been a good method. The coherence length of
code written at a terminal has a bad habit of being equal to the number
of lines that fit on a display page. Everyone does it for tiny throw
away programs but it isn't advisable for anything bigger.

My on-screen stuff is mostly engineering utilities or one-time calcs;
I'd never ship quickie things like this. But of you're arranging a
screen display, the easiest thing to do is run the code, see how it
looks, and tweak for beauty, as opposed to planning every character
location in advance. Small design iterations can take, literally, 10
seconds. Embedded stuff I write, assemble, read, tweak, read, until it
looks perfect, before I ever run it. Reading is a much better way to
debug than testing. Reading is also a lost art in many circles.

In big systems, roughly half of the bugs are invisible, being module
interactions, so no module author is likely to spot them by reading
his code. So bugs are found by testing, many of that testing done by
users. There must be a better way.

John

.

Relevant Pages

  • Re: BED BUGS OMG!!!!
    ... Yep, sure enough, bed bugs. ... Finally we get to the island itinerary and can spend some time off of the ship and think about something other than bugs. ... He stated that he had a terrific extermination team however, acknowledged that docking in NYC presents a particular problem as NYC is known to have a dramatic bed bug problem. ... I asked that we be provided with a letter acknowledging our complaint so I may have some instrument to persuade NCL to take some responsibility should we in fact bring this home, but that we would never get. ...
    (rec.travel.cruises)
  • Re: Update: Web browsers - a mini-farce (MSIE gives in)
    ... > crash due to an unfortunate sequence of commands or opening a corrupted ... there's a requirement that the software actually *SHIP* ... a prime number of dolphins (the ceteans, not the football players) in the same ... "Testing can prove the presence of bugs, ...
    (Bugtraq)
  • Re: BED BUGS OMG!!!!
    ... Yep, sure enough, bed bugs. ... with a manager privately. ... off of the ship and think about something other than bugs. ... He stated that he had a terrific extermination ...
    (rec.travel.cruises)
  • Re: Royal Caribbean Sees No Problem With Twin Beds For Anniversary Trip
    ... the ship that met the grade of quality I had paid for. ... cabin in the category you paid for. ... So Royal Caribbean did not make the mistake--the passenger did. ...
    (rec.travel.cruises)
  • Re: BED BUGS OMG!!!!
    ... Yep, sure enough, bed bugs. ... with a manager privately. ... off of the ship and think about something other than bugs. ... He stated that he had a terrific extermination ...
    (rec.travel.cruises)
Loading