Top replies by programmers when their programs don't work:

• It works fine on MY computer
• Who did you login as ?
• It's a feature
• It's WAD (Working As Designed)
• That's weird...
• It's never done that before.
• It worked yesterday.
• How is that possible?
• It must be a hardware problem.
• What did you type in wrong to get it to crash?
• There is something funky in your data.
• I haven't touched that module in weeks!
• You must have the wrong version.
• It's just some unlucky coincidence.
• THIS can't be the source of THAT.
• It works, but it's not been tested.
• Somebody must have changed my code.
• Did you check for a virus on your system?
• Even though it doesn't work, how does it feel?
• You can't use that version on your system.
• Why do you want to do it that way?
• Where were you when the program blew up?
• I thought I fixed that.

These matrices are probably as old as any other software metrics. You can also measure your software projects using these and also what type of testing you rather not do.

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

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 in the bottle.

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

Types of testing that we'd like not to see

• AGGRESSION TESTING: If this doesn't work, I'm gonna kill somebody
• COMPRESSION TESTING: []
• CONFESSION TESTING: Okay, okay, I did program that bug
• CONGRESSIONAL TESTING: Are you now, or have you ever been a bug?
• DEPRESSION TESTING: If this doesn't work, I'm gonna kill myself
• EGRESSION TESTING: Uh-oh, a bug... I'm outta here
• DIGRESSION TESTING: Well, it should work, but let me tell you about my truck...
• EXPRESSION TESTING: #@%^&*!!!, a bug!
• OBSESSION TESTING: I'll find this bug if it is the last thing that I do
• OPPRESSION TESTING: You will test this, now!
• REPRESSION TESTING: It's not a bug, it's a feature.
• SUCCESSION TESTING: The system is dead. Long live the new system!
• SUGGESTION TESTING: Well, it works but wouldn't it be better if...
• PRESIDENTIAL TESTING: Using the definition of testing as defined in the affidavit...