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.
|