Moving On

The time has come (some would say long passed) for me to leave CodeBetter. I’m feeling the itch to do my own thing and I think there’s a lot of talented and outspoken developers out there who can better benefit from the massive reach CodeBetter brings.

It’s been quite an honor to be associated with the fine folks here and I look forward to reading awesome technical content going forward. To say I’m completely ditching is a bit of a stretch; I’ll be lurking on the CodeBetter back channel giving all kinds of unsolicited and cranky advice and even guest blogging as a “CodeBetter Alumn” when I have something developer-esque to get off my chest.

Meanwhile, I haven’t stopped blogging! In fact, I have renewed motivation for writing and am picking back up at my old site, If you want to keep receiving my stuff, you can subscribe at You can expect most of my content going forward to be about the design, planning, process and coaching aspects of software development.

So, yeah… thanks, everybody! Now back to your regularly scheduled program.

Posted in Uncategorized | 1 Comment

The High Cost of Losing a Developer

You’ve probably heard statistics about the “high cost of losing a customer.” The theory is simple and true (fact?): keeping existing customers and repeat business is much more profitable than attracting new customers. Here are a few facts from

– For every customer who bothers to complain, there are 26 others who remain silent.
– The average “wronged” customer will tell 8 to 16 people.
– 91% of unhappy customers will never purchase services from you again.
– It costs about five times as much to attract a new customer as it costs to keep an old one.
– Each one of your customers has a circle of influence of 250 people or potential customers who hear bad things about you!

The point of this post is simple: RETAIN YOUR GOOD DEVELOPERS. Getting someone up to speed on a legacy codebase takes a long time and is an expensive undertaking. A large part of the software coach’s or manager’s job is attracting, developing and keeping talent. And that talent becomes more valuable over time.

Yes, you might be able to replace someone at a lower annual salary, but you have to take into account the complexity of your code portfolio in how long it’ll take to make that person productive. A $60K/annum employee may very well take $120K before reaching the productivity level and contribution of the developer who left the team.

Posted in business, management, systems thinking, teams | 30 Comments

Code Coverage: What Is It Good For?

Absolutely nothing. Or so the story goes…

I had a mini-exchange with my pal Glenn Block last night on Twitter. He was recycling the somewhat old meme that code coverage is a cockamamie metric that, as he puts it, ” a false security blanket on quality”.

Measurements (other than net profit, of course) are merely indicators. They give us insight into what we’re doing, red flags that help us know when to follow up on and drill into with more qualitative and hands on tools.This is, more-or-less, the idea behind Autonomation or “automation with a human touch.”

For example: while code coverage isn’t proof that our testing efforts will yield higher maintainability, it does tell us a teams commitment to a test practice.

I tend to believe the most interesting indicators are composite metrics. What happens when we start thinking about combining code coverage with cyclomatic complexity? I’d like to read a (hopefully) inverse relationship over time, coverage rising while complexity falls, as a good indicator that we’re doing simple design.

The important thing to remember about metrics is they are only single purpose tools which, correctly applied, gift us with little tidbits of insight. It’s up to you to find meaningful and creative uses for the various metrics and their various combinations. Once you start doing that, measurements like code coverage can certainly help you achieve your immediate goals.

Posted in Metrics, practices, TDD, teams, testing | 10 Comments

December 2-3 London Workshop Update

Forgive the self-promotional interruption, but quick housekeeping note:

I’ve asked the company hosting my workshop in London to reduce the price of my 2-day workshop on December 2-3 aimed at tools and techniques technical leads, folks interested in lean, standard work, etc. to try to get as many people there (it’s a group collaboration focused thing). I also want to get as much feedback as I can. If you book before November 15th, the price is £550.

Register at the SkillsMatter site. Also feel free to contact me with any questions laribee/AT/gmail/DOT/com.

Posted in announcements, housekeeping | 1 Comment


I’m completely obsessed with the idea of low-technology:

The term low-technology is a description of those crafts and tools whose inception (typically) predates the Industrial Revolution.

A test for low-technology may be that it can be practiced or fabricated with a minimum of Capital investment by an individual or small group of individuals; and that the knowledge of the practice can be completely comprehended by a single individual, free from increasing specialization and compartmentalization.

An excellent overview of some of the cutting edge efforts in low-technologies can be seen in this TED video with low-technologist Amy Smith. I completely agree with when says, “not all inventions need to be grandiose, complex things… sometimes they can be simple and smart ideas that just help a lot of people.”

The second block quote is where I’m coming from. What are those tools in software development that add lots of value without minimal getting started overhead. Pair-programming seems like an excellent example of low technology. Emergent design, test-driven development and value-driven approaches like XP are yet more.

It seems, to me anyway, that these are the things that’ll yield the most benefits. Both vendor-supplied tooling and trending topics we hold near and dear, like Domain-Driven Design and DSLs and this fluent madness in general, strike me as more high-technology approaches.

There’s nothing wrong with high-technology, of course, but my instinct is that the risk-reward equation for most teams usually favors low-technology. We have, after all, limited bandwidth and attention, so my vote will ever go to what I see as big and easy wins: stuff focused on beefing up the signal of our communication as a team and community against the noise we might get as a software fashion victim.

Anyway, this is a key topic I’ll be centering on over the next little while and thought y’all might find this way of looking at our kit, our standard tradecraft at least a little bit interesting.

Posted in coaching, low-technology, opinion, practices, TDD, teams, XP | 12 Comments