httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor J. Orlikowski" <>
Subject [Off-topic] Apache release schedule
Date Tue, 20 Feb 2001 15:00:03 GMT
Trolling along in rec.humor.funny.reruns for the first time in a
while. I'm certain some of you have seen this before, but it seems

From: (Patti Beadles)
Subject: Software Metrics
Keywords: original, funny, originally appeared in fourth quarter, 1993
Newsgroups: rec.humor.funny.reruns
Followup-To: rec.humor.d
Date: Mon, 19 Feb 2001 7:20:00 PST
Message-id: <>
Xref: rec.humor.funny.reruns:1651

The software engineering community has been placing a great deal of
emphasis lately on metrics and their use in software development.  The
following metrics are probably among the most valuable for a software

The Pizza Metric
	How:	Count the number of pizza boxes in the lab.
	What:	Measures the amount of schedule under-estimation.
		If people are spending enough after-hours time
		working on the project that they need to have
		meals delivered to the office, then there has
		obviously been a mis-estimation somewhere.

The Aspirin Metric
	How:	Maintain a centrally-located aspirin bottle for use
		by the team.  At the beginning and end of each month,
		count the number of aspirin remaining aspirin in the 
	What:	Measures stress suffered by the team during the project.
		This most likely indicates poor project design in the
		early phases, which causes over-expenditure of effort
		later on.  In the early phases, high aspirin-usage
		probably indicates that the product's goals or other
		parameters were poorly defined.

The Beer Metric
	How:	Invite the team to a beer bash each Friday.  Record the
		total bar bill.
	What:	Closely related to the Aspirin Metric, the Beer Metric
		measures the frustration level of the team.  Among 
		other things, this may indicate that the technical 
		challenge is more difficult than anticipated.

The Creeping Feature Metric
	How:	Count the number of features added to the project after
		the design has been signed off, but that were not requested
		by any requirements definition.
	What:	This measures schedule slack.  If the team has time to add
		features that are not necessary, then there was too much 
		time allocated to a schedule task.

The "Duck!" Metric
	How:	This one is tricky, but a likely metric would be to
		count the number of engineers that leave the room when
		a marketing person enters.  This is only valid after a
		requirements document has been finalized.
	What:	Measures the completeness of the initial requirements.
		If too many requirements changes are made after the product 
		has been designed, then the engineering team will be wary
		of marketing, for fear of receiving yet another change to
		a design which met all initial specifications.

The Status Report Metric
	How:	Count the total number of words dedicated to the project
		in each engineer's status report.
	What:	This is a simple way to estimate the smoothness with which
		the project is running.  If things are going well, an item
		will likely read, "I talked to Fred; the widgets are on 
		schedule."  If things are not going as well, it will say,
		"I finally got in touch with Fred after talking to his
		phone mail for nine days straight.  It appears that the
		widgets will be delayed due to snow in the Ozarks, which
		will cause the whoozits schedule to be put on hold until
		widgets arrive.  If the whoozits schedule slips by
		three weeks, then the entire project is in danger of
		missing the July deadline."

>From the RHF archives as selected by Brad Templeton, Maddi Hausmann and
Jim Griffith.  This newsgroup posts former jokes from the newsgroup

Web users, you can read a random joke from the archives just by bookmarking

Victor J. Orlikowski

View raw message