A Guide to Software Revisions 1.0: Also known as "one point uh-oh", or "barely out of beta". We had to release because the lab guys had reached a point of exhaustion and the marketing guys were in a cold sweat of terror. 1.1: We fixed all the killer bugs ... 1.2: Uh, we introduced a few new bugs fixing the killer bugs and so we had to fix them, too. 2.0: We did the product we really wanted to do to begin with. Mind you, it's really not what the customer needs yet, but we're working on it. 2.1: Well, not surprisingly, we broke some things in making major changes so we had to fix them. But we did a really good job of testing this time, so we don't think we introduced any new bugs while we were fixing these bugs. 2.2: Uh, sorry, one slipped through. One lousy typo error and you won't believe how much trouble it caused! 2.3: Some jerk found a deep-seated bug that's been there since 1.0 and wouldn't stop nagging until we fixed it!! 3.0: Hey, we finally think we've got it right! Most of the customers are really happy with this. 3.1: Of course, we did break a few little things. 4.0: More features. It's doubled in size now, by the way, and you'll need to get more memory and a faster processor... Drug Dealers and Software Developers: coincidence? --------------------------- --------------------------- Drug dealers Software developers --------------------------- --------------------------- Refer to their clients Refer to their clients as "users". as "users". "The first one's free!" "Download a free trial version..." Have important South-East Have important South-East Asian connections Asian connections to help move the stuff). (to help debug the code). Strange jargon: Strange jargon: "Stick," "Rock," "CSCI," "RTFM," "Dime bag," "E". "Java," "ISDN". Realize that there's Realize that there's tons of cash in the tons of cash in the 14- to 25-year-old 14- to 25-year-old market. market. Job is assisted by the Job is assisted by industry's producing industry's producing newer, more potent mixes. newer, faster machines. Often seen in the company Often seen in the company of of pimps and hustlers. marketing people and venture capitalists. Their product causes DOOM. Quake. SimCity. Duke Nukem 3D. unhealthy addictions. 'Nuff said. New York, NJ, August 27 -- People for the Ethical Treatment of Software (PETS) announced today that seven more software companies have been added to the group's "watch list" of companies that regularly practice software testing. "There is no need for software to be mistreated in this way so that companies like these can market new products," said Ken Granola, spokesperson for PETS. "Alternative methods of testing these products are available." According to PETS, these companies force software to undergo lengthy and arduous tests, often without rest for hours or days at a time. Employees are assigned to "break" the software by any means necessary, and inside sources report that they often joke about "torturing" the software. "It's no joke," said Granola. "Innocent programs, from the day they are compiled, are cooped up in tiny rooms and 'crashed' for hours on end. They spend their whole lives on dirty, ill-maintained computers, and are unceremoniously deleted when they're not needed anymore." Granola said the software is kept in unsanitary conditions and is infested with bugs. "We know alternatives to this horror exist," he said, citing industry giant Microsoft Corp. as a company that has become extremely successful without resorting to any form of software testing. PETS is a nonprofit organization dedicated to improving the lives of software programs and promoting alternatives to software testing. Software Development Process 1. Order 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 software. (The customers are a big help here.) 9. Identify bugs as potential enhancements. 10. Announce the upgrade program. Software Engineering Glossary of Product Terminology NEW: Different colours from previous version. ALL NEW: Software is not compatible with previous version. UNMATCHED: Almost as good as the competition. ADVANCED DESIGN: Upper management doesn't understand it. NO MAINTENANCE: Impossible to fix. BREAKTHROUGH: It finally booted on the first try. DESIGN SIMPLICITY: Developed on a shoe-string budget. UPGRADED: Did not work the first time. UPGRADED AND IMPROVED: Did not work the second time. Things you need to know about "REAL" Software engineers. REAL SOFTWARE ENGINEERS DON'T READ DUMPS Real software engineers don't read dumps. They never generate them, and on the rare occasions that they come across them, they are vaguely amused. Real software engineers don't comment their code. The identifiers are so mnemonic they don't have to. Real software engineers don't write applications programs, they implement algorithms. If someone has an application that the algorithm might help with, that's nice. Don't ask them to write the user interface, though. Real software engineers don't eat quiche. If it doesn't have recursive function calls, real software engineers don't program in it. Real software engineers don't program in assembler. They become queasy at the very thought. Real software engineers don't debug programs, they verify correctness. This process doesn't necessarily involve executing anything on a computer, except perhaps a Correctness Verification Aid package. Real software engineers like C's structured constructs, but they are suspicious of it because they have heard that it lets you get "close to the machine." Real software engineers play tennis. In general, they don't like any sport that involves getting hot and sweaty and gross when out of range of a shower. (Thus mountain climbing is Right Out.) They will occasionally wear their tennis togs to work, but only on very sunny days. Real software engineers admire PASCAL for its discipline and Spartan purity, but they find it difficult to actually program in. They don't tell this to their friends, because they are afraid it means that they are somehow Unworthy. Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure. Real software engineers write in languages that have not actually been implemented for any machine, and for which only the formal spec (in BNF) is available. This keeps them from having to take any machine dependencies into account. Machine dependencies make real software engineers very uneasy. Real software engineers don't write in ADA, because the standards bodies have not quite decided on a formal spec yet. Real software engineers like writing their own compilers, preferably in PROLOG (they also like writing them in unimplemented languages, but it turns out to be difficult to actually RUN these). Real software engineers regret the existence of COBOL, FORTRAN and ASIC. PL/I is getting there, but it is not nearly disciplined enough; far too much built in function. Real software engineers aren't too happy about the existence of users, either. Users always seem to have the wrong idea about what the implementation and verification of algorithms is all about. Real software engineers don't like the idea of some inexplicable and greasy hardware several aisles away that may stop working at any moment. They have a great distrust of hardware people, and wish that systems could be virtual at ALL levels. They would like personal computers (you know no one's going to trip over something and kill your DFA in mid-transit), except that they need 8 megabytes to run their Correctness Verification Aid packages. Real software engineers think better while playing WIFF 'N' PROOF. ZEN AND THE ART OF SOFTWARE DOCUMENTATION (Translated from the P'-u-t'ung hua dialect by W.C.Carlson) Editor's Note: The following are excerpts from the only known treatise on Zen Software Documentation. Called "H'ring-chu-tsu", which literally translates to "Ink of Several Insignificant Matters", this treatise was written in 12th Century Japan by the scholarly monk E'm-ie-T'. That it discusses Software documentation -- predating the advent of software by 850 years -- is but another of the mysteries of those who walk the true path.) This article should be read twice. On Preparing to Write of Software To prepare for the writing of Software, the writer must first become one with it, sometimes two. Software is untasteable, opalescent, transparent; the user sees not the software, so the writer must see through it. Spend long, quiet mornings in meditation. Do not sharpen the mind, but rather blunt it by doing Zen crosswords. (Ed. note: Zen crosswords are done by consulting only the "Down" clues; and always in the mind, never on paper.) The mind should be rooted but flexible, as a long stemmed flower faces the Sun yet bends with the Wind. Think not of compound adjectives because they tend to wire the mind in two directions. Rather, consider the snowflake, which radiates in beauty in any and all directions. Partake of strong drink. Do not study the Software; let it study you. Allow the Software admission to your mind, but keep in the cheap seats. Let it flow around you at its own pace. Do not disturb or dismay it, but keep it from your private parts because it tends to coalesce there. When the Software is with you, you will know it. It will lead your mind where it should be, and prepare you for the narcolepsy that is cert ain to follow. You will know when the Software is with you, and so will others. You will smile with an inner smile. Typewriters will frighten you. You will fall down a lot. The first exercise in writing Software documentation is the Haiku. Haiku are 17 syllable poem forms in which many ideas of a single concept are reduced -- nay, distilled -- into a short, impressionistic poem. For example, the Haiku for preparing to write of Software goes: Emptiness on paper; Fleeting thought. Red Sox play at Fenway's Green Park. By concentrating on the Softwares form and function in a concise, subliminal, truly meaningless Haiku verse, you have transcended the Software, and you can then write the true manual. The following Haiku is from a Zen manual on Data Transmission: How swiftly whirls the disk; Data leaps to the floating head And is known. And this is on Hardware Maintenance: The smell of hot P.C. card, Blank screen, no bell, New parts will be needed. And another Haiku, this one on Debugging: All the lights are frozen; The cursor blinks blandly. Soon, I shall see the dump. Let the Haiku thoughts free your mind from your fingers. Your fingers will write what must be written. Soon you will be in Doc. Prep. On the Review Cycle This is the murkiest path. Storms gather and disperse around you many directions, none of which are in English. The path becomes unclear as many an idea compete for attention. Some of them are fatal. But the writer of Zen Software documentation fears not the turbulence of review cycles. Let it storm around you and be dry, warm, and safe in the knowledge that you have written the pure manual. Anyway, you know the printer. You shall in the end have it your way. |
|