Re: Larkin, Power BASIC cannot be THAT good:

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.

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.

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.

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.

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.

I think the cumulative updates to XL2007 (original boxed version) now top 1GB. After all everyone that matters has broadband these days.

The big difference now is that nothing physically has to ship.

Yes, and that makes people care less about bugs. And when a product is
so complex that each bug fix spins off more bugs...

Some of the complexity is unavoidable in very large systems. Your experience with one programmer few months projects does not scale well.

A rough guide is that every attempted non-trivial bug fix in a large project has a 50% risk of causing an unwanted side effect. It means some are worth leaving in if there is a workaround.

I always recall IBM's FORTRAN G compiler which was so uncertain of its world view that the result of a successful compilation was:
NO DIAGNOSTICS GENERATED?

Debug showed that the string length of the message was miscounted and the trailing NUL was being printed as "?". Rumour had it that their change procedures made it too onerous to correct this minor cosmetic fault.

Regards,
Martin Brown
.

Relevant Pages

  • Re: smp dead lock of io_request_lock/queue_lock patch
    ... We have a fix for a correctness issue ... > bug reports of it ever happening, and which has been integrated into our ... we always push new kernels to all of our customers ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: HELP! RECENTLY ADDED ISSUES!
    ... Without the ability to reproduce the issue, the team could only guess at how to fix the issue, which of course largely precludes any advancement towards a fix at any point ever. ... What would be helpful would be for you to have one of your customers zip up their database file and send it to you. ... That is one way that we know it is a bug. ...
    (microsoft.public.windowsmedia.player)
  • Re: An Open Letter To The Linux Enthusiasts.
    ... >>them fix their software so that saying hello does not annoy them. ... I want their customers to annoy MS, ... don't care how they do it, but the obvious route is "complain to MS" ... about that bug, and many more, until MS are good and riled and fix it. ...
    (alt.os.linux)
  • Re: smp dead lock of io_request_lock/queue_lock patch
    ... has the fix you pushed in RH-9.0 been push to EL customers? ... it's a bug fix for a deadlock that _could_ trigger on SMP ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • [Un] Unangband 0.6.3 released
    ... Allow player to assemble friendly monsters and carry eggs to hatch ... Updated druidic spells to use new region code. ... Fix lockup bugs generating the Old Forest. ... Fix bug where items dropped by monster death would infinitely ...
    (rec.games.roguelike.announce)