Using software metrics for managing developers is usually frowned upon. That's too bad because they sure make software management fast and easy - as demonstrated in the video "Metrics-Based Software Management - A Hands On Approach".

Any software metric can be abused or misused, but does this mean we should avoid any and all software metrics? Joel Spolsky, Eric Sink, and I have an interesting, late night, conversation.

After much talking, experimenting, and blogging, we implemented a prototype version of crap4j - a code Change Risk Analyzer and Predictor (i.e. CRAP) for Java. A tool to help you defend yourself against overly complex and untested code. Read all about it and find out how to download and install the crap4j Eclipse plug-in.

How to inject beauty in a coyote ugly code base.

In Part I we ask the question: "Is there a place and opportunity for truly beautiful code and programming pearls in real world of legacy applications and enterprise software?".

Testivus wisdom on the proper use of software metrics.

Part II - We let the C.R.A.P. out of the bag. We explain our thinking behind the first version of the CRAP metric and then unveil the formula.

Part I - Beauty and The Beast. I begin my exploration of ugliness in code with some background and an overview of what most people consider to be crappy code.

Answer to the question: "What is Testivus' wisdom concerning the proper percentage of test coverage?"

Some good advice on developer and unit testing, packaged as cryptic bits of ancient Eastern wisdom in the hope of getting your attention.

This is the fourth installment in the "Working Effectively With Characterization Tests" series. This time we look at how automation can help you create and/or improve your characterization tests using JUnit Factory, a free, web-based, experimental characterization test generator (and my pet research project).

In this 3rd part of the series, we put our newly created characterization tests to work, and we see how even the simplest and most innocent code changes can cause unexpected and unwanted changes in the behavior of our code. Fortunately our characterization tests are there to protect us.

In part 2 of the series we look under the hood of legacy code we inherited and experience a moment of panic when we see how cryptic the code is. Then present a simple strategy that does not require us to fully understand the code in order to write good characterization tests.

This is the first installment in a series of short articles I plan to write on characterization testing. Characterization testing is an important concept and an essential tool for software developers working with legacy code (i.e. most of us) and it deserves broader exposure and more attention.

Testing is tough for most programmers, but without some amount of developer testing delivering quality software is even tougher. We propose a new software specialization and position – Developer Testing Master – to help software organizations fill the horrifically expensive testing gap between development and QA.