Quality Engineering —2 min read
20% of the code is executed 80% of the time

If code offers business value, it's worth ensuring correctness with tests. If it's not worth doing correctly, just delete it.

Coding Practices —4 min read
What is the ROI of Test-Driven Development?

Common break-even calculations for TDD are wrong when experienced TDD devs are involved becuase TDD makes development faster.

Software Delivery —9 min read
These Days Proper CI is Table Stakes

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

Coding Practices —8 min read
Automated Testing False Dichotomy #2: All vs None

This is the second installment in my series The False Dichotomies of Automated Testing. If you’ve ever met a recent test convert, you’ve probably heard them talk about the mythical creature that is “100% test coverage.” As with most benevolent mythical creatures, this one is highly sought after, and possibly even worshiped. It is claimed to have magical powers, although the precise nature of these powers is often hotly debated even among the most ardent of believers.

Coding Practices —6 min read
The False Dichotomies of Automated Testing

This is the first in a series of posts about automated testing for software developers. I’ve been fascinated by this thing called “programming” since I first learned I could enter BASIC programs into my family’s Commodore 64 when I was 8 years old. I became a full-time software developer in 2006. And I “got religion” about automated tests shortly after that. But still not everyone is as “enlightened” as I am when it comes to writing automated tests.

Coding Practices —4 min read
One thing I miss about unit tests: Unit tests as Documentation

I wrote this post in October of 2015 as I was adjusting to life without unit tests at a new job. I recently stumbled upon it in my Drafts, and edited it down to a single point for publication. In October of last year I took a new job at a company with a large group of programmers, and an old (15+ years) code base. The new company doesn’t generally do unit tests, for various historical reasons, none of which make much sense upon close examination.