Software development cycle

Astronuc

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. Repeat three times steps 3 and 4.

6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.

7. Users find 137 new bugs.

8. Original programmer, having cashed his royalty check, is nowhere to be found.

9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.

10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.

11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.

12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.

13. Programmer produces code he believes is bug-free.

dduardo

Here is another development cycle:

1. Develop some code and relase it under an open source license
2. Let others develop the program for you.
3. Profit

ramollari

No kidding!
Bug-free programs don't exist. The point is not how to remove bugs and errors, but how to decrease the number of errors per lines of code.

Because everything has become commercial, development teams don't focus on quality, but overall profit or short development cycle or tender winning. We hear 'horror stories' about mission critical buggy software (beaming machines that baked the patients, failing ambulance systems, etc).

So, American companies, and Microsoft in particular, are notorious for buggy software. Programmers still retain the 'hacker' culture of 'code and fix' software development. Japan is currently producing the software of highest quality.

As a final note, Astronuc is right, fixing a software bug gives rise to more bugs. Software is a beast, yeah!

The volunteers are the 'suckers'.

chroot

There are methodologies that are useful in developing bug-free software; the one with which I am most familiar is called "Cleanroom Software Engineering." It was originally developed at IBM, but now is used in many places. It is admittedly rather tedious and boring to use, at least at first, but it has been shown many time to reduce the number of errors per line of code by several orders of magnitude.

- Warren

graphic7

How would anyone profit from open source development?

What little software development that I actually do (I do more system administration), I use cvs heavily along with vi and jedit. If I'm writing something more complex, I'll use Sun Forte, which has some nice features like makefile generation (not that I'm lazy, however, I like to be efficient) and supports a multitude of languages.

faust9

Nero is releasing a Linux version of their CD burning software. They are profiting from open source(though they are not open source). RedHat turns a profit. Mandrake has turned its books around and turns a profit. Your beloved Sun is drifting toward open source. You use this site, so you profit from open source.

You should ask yourself how anyone profits with OSS being the competition. Every passing day leads more ppl toward OSS (and companies i.e. SUN).

OSS is profitable (MySQL).

[edit] Apple turns a fat profit from OSS, as does IBM.

graphic7

I'm referring to receiving the profits (money) from the developer aspect. Red Hat is having a fit over CentOS and White Box Linux. Both of the distributions are spoiling Red Hat's plans for RHEL. Red Hat's profits mainly come from support. Support is the main reason people choose to buy RHEL, otherwise, they'd just download CentOS. Mandrake gets money the same way - support and updates. Sun isn't directly profitting from OSS. They are open sourcing Solaris to encourage the adoption of their UltraSparc and Opteron systems, along with charging for licenses for Sun One and Sun support contracts. I use this site; however, do I make any cash from using this site and making use of it's OSS?

Funny you say MySQL. MySQL receives profits from people including MySQL in propiertary products, which is roughly around $1000/user. Certainly this isn't chunk change. Are you also aware that MySQL charges for licensing of their JDBC module? They do. Such hypocracy should be obvious.

How in the world does Apple turn a profit from OSS? They pillage OSS (FreeBSD), add Cocoa, Aqua, etc. and sell it as OS X. They charge for updates. In no way does this say that Apple is directly profitting from OSS. How can you? IBM uses OSS to encourage the adoption of their POWER systems and servers or slowly leading up users to buying the propiertary products like WebSphere with tons of OSS plugins, as does Sun.

ramollari

Blah blah blah! There is a very profitable industry from open source software, one cannot deny it! Even the original developers do!

faust9

Man alive!!! You hate being wrong so much that you will twist a simple concept such as
profit to suit your own ego. I'm not going to address your rambeling post because you showed that these companies ARE making money off of OSS. Developers do get paid. It is profitible.

saltydog

Hello guys. I use to design testing protocols for newly-developed software in an FDA-regulated environment. You can get it pretty bug-free if corporate is willing to spend the money. And yes I say "pretty well" as you can't guarantee it to be bug-free. Also, the more you use it, the more reliable (fewer bugs) it becomes. Finally, if you correct the bugs in a carefully controlled envirnoment (software change control being implemented), then the act of fixing the bugs can be controlled to reduce the chance of causing more bugs.

The philosophy of testing should be: Test with the objective of finding errors. If no errors are found, the objective of the testing was not met. Thus the objective of the testing is to fail the objective.

ramollari

By 'using' you don't change the software.

You're saying that the objective of testing is to find as many errors as possible and now you say it is to find as few errors as possible! You should rather say that the desired result of testing is to find as few errors as possible (which doesn't mean to fail the objective).

Jimmy Snyder

Every program has bugs.
Every program can be shortened by one line.

Therefore, every program can be written in one line, but that line will be wrong.

eNathan

develop
test
debug * sqr(Lines_Of_Code)
release

Jimmy Snyder

100 level 3 bugs in the source
100 level 3 bugs
You fix the code,
compile, and reload
104 level3 bugs in the source

104 level3 bugs in the source
104 level3 bugs
You fix the code,
compile, and reload
115 level3 bugs in the source

...

eNathan

Bugs in my softawe usually done see light until I release it :-s So from now on all of my programs will be released as 0.9 Beta instead of V1.0

saltydog

No. I'm saying the objective of the testing is to find as many errors as possible:

The ultimate objective is to use reliable code that has as few bugs as possible. In order to achieve this, the testing should be approached aggressively with the objective of purposefully making it fail. Thus if you fail to make it fail, your testing objective was not met but your ultimate objective was. That's why the author of the software should never test the software. That person is less likely to "abuse" the software in a way that meets the objectives of the testing.

saltydog

You know, I want to qualify something I said for my peace of mind and also if someone calls me on it: I meant pretty bug free for a single (or perhaps several) average sized programs. Although I tested systems with 1000s of programs, I cannot say they were "pretty bug free" and in fact contained many bugs (non-critical) even after extensive testing was performed . . . but I didn't write those.