www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Software life cycle

reply Walter Bright <newshound digitalmars.com> writes:
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
Jul 14 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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>
Jul 14 2006
parent reply BCS <BCS pathlink.com> writes:
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.
Jul 14 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
Jul 14 2006
prev sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
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.

-- 
Jul 14 2006
parent reply MFH <MFH_member pathlink.com> writes:
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
Jul 20 2006
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
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
Jul 20 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
Jul 21 2006