Gidd, I like it. Here's a compliment to your post: 101 ways to know your software project is doomed. http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doo med/ Cheers!
________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Gidd Sent: Friday, July 20, 2007 6:17 AM To: [email protected] Subject: OT:Friday Humor ** Software Revision Levels Explained How should a revision level be interpreted? Here's a quick guide for anyone short of a clue: 0.1 WE GOT A REALLY GREAT NEW WAY TO DO THINGS !!! <0.9 Not ready for prime time. 0.9 We think it works, but we won't bet our lives on it. 1.0 Management is on our case; seems like a low risk. 1.01 Okay, we knew about that. All known bugs are fixed. 1.02 Fixes bugs you won't see in 27,000 years, i.e. more than three times the age of the universe. 1.03 Fixes bugs in the bug fixes. 1.04 All right, this REALLY fixes all known bugs. 1.05 Fixes bugs introduced in rev 1.04. 1.1 A new crew hired to write documentation. 1.11 From now on, no comma after "i.e." or "e.g.". 1.2 Somebody actually changed a functional feature. 2.0 New crew hired to write software. Old crew blamed for bugs. 2.01 New crew sending out resumes to placement agencies. 3.0 Re-write the software in another language, go back ten squares. ... return to line 0.1 The Software Development Process 1) Order the T-shirts for the Development team 2) Announce availability 3) Write the code 4) Write the manual 5) Hire a Product Manager 6) Spec the software (Writing the specs after the code helps to ensure that the software meets the specifications) 7) Ship 8) Test (the customers are a big help here) 9) Identify bugs as potential enhancements 10) Announce the upgrade program __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
