Shamelessly cribbed from slashdot:

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
5. See 3.
6. See 4.
7. See 5.
8. See 6.
9. See 7.
10. See 8.
11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.
12. Users find 137 new bugs.
13. Original programmer, having cashed his royalty check, is nowhere to be found.
14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
18. Programmer produces code he believes is bug-free.
19. See step 2

Walter Bright wrote:
> Shamelessly cribbed from slashdot:
> 
> 1. Programmer produces code he believes is bug-free.
> 2. Product is tested. 20 bugs are found.
> 3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
> 4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
> 5. See 3.
> 6. See 4.
> 7. See 5.
> 8. See 6.
> 9. See 7.
> 10. See 8.
> 11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.
> 12. Users find 137 new bugs.
> 13. Original programmer, having cashed his royalty check, is nowhere to be found.
> 14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
> 15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
> 16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
> 17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
> 18. Programmer produces code he believes is bug-free.
> 19. See step 2

No way!! That's not 'real world' at all (it's too "Pollyannaish" - things are really worse)! <g>

Dave wrote:
> Walter Bright wrote:
> 
>> Shamelessly cribbed from slashdot:
>>
>> 1. Programmer produces code he believes is bug-free.
>> 2. Product is tested. 20 bugs are found.
>> 3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
>> 4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
>> 5. See 3.
>> 6. See 4.
>> 7. See 5.
>> 8. See 6.
>> 9. See 7.
>> 10. See 8.
>> 11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.
>> 12. Users find 137 new bugs.
>> 13. Original programmer, having cashed his royalty check, is nowhere to be found.
>> 14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
>> 15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
>> 16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
>> 17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
>> 18. Programmer produces code he believes is bug-free.
>> 19. See step 2
> 
> 
> No way!! That's not 'real world' at all (it's too "Pollyannaish" - things are really worse)! <g>

yah, you droped a few zeros on all of the bug counts.

Walter Bright wrote:

<skipped>

I think Test-driven development was proposed to address this issues (or at least reduce their effect).

And D with built-in DbC and unit tests fits here quite well.

-- 

BCS wrote:
> Dave wrote:
>> Walter Bright wrote:
>>
>>> Shamelessly cribbed from slashdot:
>>>
>>> 1. Programmer produces code he believes is bug-free.
>>> 2. Product is tested. 20 bugs are found.
>>> 3. Programmer fixes 10 of the bugs and explains to the testing
>>> department that the other 10 aren't really bugs.
>>> 4. Testing department finds that five of the fixes didn't work and
>>> discovers 15 new bugs.
>>> 5. See 3.
>>> 6. See 4.
>>> 7. See 5.
>>> 8. See 6.
>>> 9. See 7.
>>> 10. See 8.
>>> 11. Due to marketing pressure and an extremely pre-mature product
>>> announcement based on over-optimistic programming schedule, the
>>> product is released.
>>> 12. Users find 137 new bugs.
>>> 13. Original programmer, having cashed his royalty check, is nowhere
>>> to be found.
>>> 14. Newly-assembled programming team fixes almost all of the 137
>>> bugs, but introduce 456 new ones.
>>> 15. Original programmer sends underpaid testing department a postcard
>>> from Fiji. Entire testing department quits.
>>> 16. Company is bought in a hostile takeover by competitor using
>>> profits from their latest release, which had 783 bugs.
>>> 17. New CEO is brought in by board of directors. He hires programmer
>>> to redo program from scratch.
>>> 18. Programmer produces code he believes is bug-free.
>>> 19. See step 2
>>
>>
>> No way!! That's not 'real world' at all (it's too "Pollyannaish" -
>> things are really worse)! <g>
> 
> yah, you droped a few zeros on all of the bug counts.

Maybe this was just a tiny framework for hello world programs. :) I wonder what happens to all those (lucky) original programmers. Do they start as CEO's in some smaller companies like DigitalMars? Sorry Walter, just joking - everybody knows you're the god. ;)

You know, these M$ bugs really annoy me. This year I have only used their products for ~10 hours. Last week I was going to add an extended partition to a friend's machine using the WinXP computer management tool. Surprise surprise, it managed to wipe out all existing extended partitions with id 0x83 (linux partitions). Luckily I was able to restore the partition table using an utility called testdisk (http://www.cgsecurity.org/wiki/TestDisk).

-- 
Jari-Matti

In article <e98u4v$ogc$1@digitaldaemon.com>, Andrei Khropov says...
>
>Walter Bright wrote:
>
><skipped>
>
>I think Test-driven development was proposed to address this issues (or at least reduce their effect).
>
>And D with built-in DbC and unit tests fits here quite well.
>
>-- 
>

unless the name of all "standard" modules is changed to
new.std.windows.windows.windows
or
std.d.stdio
or so...

Unfortunately, almost *NO* D program older than some months compiles today !

(don't get me wrong, I am a *supporter* of D, but there are things that should be avoided in the future if D is to survive...)

--MFH

On Thu, 20 Jul 2006 23:24:19 +0000 (UTC), MFH wrote:

> In article <e98u4v$ogc$1@digitaldaemon.com>, Andrei Khropov says...
>>
>>Walter Bright wrote:
>>
>><skipped>
>>
>>I think Test-driven development was proposed to address this issues (or at least reduce their effect).
>>
>>And D with built-in DbC and unit tests fits here quite well.
>>
>>-- 
>>
> 
> unless the name of all "standard" modules is changed to
> new.std.windows.windows.windows
> or
> std.d.stdio
> or so...
> 
> Unfortunately, almost *NO* D program older than some months compiles today !
> 
> (don't get me wrong, I am a *supporter* of D, but there are things that should be avoided in the future if D is to survive...)
> 
> --MFH

Ummm??? Build is a lot older than a few months and contains some many thousands of lines, and it compiled using v0.163 without me having to change a single line.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
21/07/2006 10:02:57 AM

In article <e9p3b3$199m$1@digitaldaemon.com>, MFH says...
>
>In article <e98u4v$ogc$1@digitaldaemon.com>, Andrei Khropov says...
>>
>>Walter Bright wrote:
>>
>><skipped>
>>
>>I think Test-driven development was proposed to address this issues (or at least reduce their effect).
>>
>>And D with built-in DbC and unit tests fits here quite well.
>>
>>-- 
>>
>
>unless the name of all "standard" modules is changed to
>new.std.windows.windows.windows
>or
>std.d.stdio
>or so...
>
>Unfortunately, almost *NO* D program older than some months compiles today !
>
>(don't get me wrong, I am a *supporter* of D, but there are things that should be avoided in the future if D is to survive...)

This is due to improvements in DMD. Usually the the changes required are minimal (and the compiler's error messages typically gives good hints). I don't think that the evolution of D has been as big of a problem recently for projects that are being maintained.

The changes in a typical release of DMD usually provides more goodies than gotchas.

And I think we're getting really close to a D 1.0 release which would mean that 1.0 features would be frozen and we'd only get bug fixes. That would help a lot with the issue of code becoming obsolete.

jcc7