Why is your organization delivering software that sucks?
How do you define "crap?"
How do your customers define "crap?"
What are you testing?
When are you testing?
Why are you testing?
Who is doing the testing?
What are you measuring?
When are you measuring?
How do you interpret what the measurements are telling you?
Thats a few questions to start with. Many organizations I have worked with measure NOTHING until the product ships and customer reports the bugs. Thats analogous to designing and building a car and measuring NOTHING until a customer buys the car, drives it off the lot and the wheels fall off.
Other organization measure things but don't know what to do with the measurements. So, they have data but can't act on it. They feel really good that they have data and its presented in power point 
But the value of the measurements is zero.
But the value of the measurements is zero.Start simple - only measure things that you can interpret and act on.
Examples of a few things to measure:
- eLOC - effective lines of code in methods and in class
- CC - cyclomatic complexity
- parameters in a method signature - how many things get handed into a method
- ratio of comments to LOC written
- number of places that call a method (afferent coupling)
How do I use these?
None of them, in of of themselves tell you something is good or bad. They tell you where to do further research.
As a single measure they are good but not great indicators of trouble.
Examples
- CC>20 - usually means the methods pretty complex.
- Method eLOC > 70 - thats a lot of code in a method to get bug free and mantain
- method parameters > 6 - why so many things getting handed in? Oten indicates a not very OO design
- afferent coupling > 15 - lots of things in the code depend on this thing being bug free - better write good unit tests against this method, especially. Maybe the code is too coupled to this, take a look at the design.
But look at the code over all and get a distribution to see if you have only a few high CC or eLOC methods or is the whole code base like this? the answer will tell you what you need to do next - fix the code or fix the team.
Use them combined together to find real trouble spots.
- Methods with high CC, high afferent coupling and LOW e:LOC may indicate poorly coded but really important methods.
- High eLOC with low CC usually means code that just doing copies from one field to another - take a look at your design, how OO is it?
- High CC and low ratio of comments is usually a bad sign. A complicated algo that nobody documented. Remember - commenting is more than documenting, its a mental check that the coder thought through the problem. As complexity of an algorithm goes up, likelihood of bugs goes up exponentially NOT linearly.
Track the trend over time:
- Watch how CC distribution changes from week to week to week. Watch for "knees" in the curve. This is the start of trouble. Catch it early.
- Watch eLOC - over time the amount of new code added should DECREASE at some point. Even shrink due to refactoring that removes redundant code and builds tighter code. If you are seeing it, you should ask why.
- Watch the size of the UNIT TESTS - a unit test that is >60 LOC is just as likely to have bugs as the actual product code. Buggy unit tests are a false sense of security.
Create a workflow process for metrics and manage the process as part of your SDLC:
- Design -> Code -> Measure -> Interpret Metrics-> Review Designs/Code identified in metrics —> Recommend Changes based on Reviews -> Implement Recommendations -> VERIFY recommendation were implemented
- Treat these refactorings like real requirements - backlog them, estimate impact,, schedule, execute
- Measure the efficacy of your process
Tips:
- Dont measure everything
- Don't measure what you can't act on - just adds noise
- A few consistent measurements repeated and tracked a better than a "firehose" of metrics
- Use tools
- Metrics data will create a data warehouse cube of data - think of it like that ahead of time - excel isn't enough of a tool to handle it
Comments