Improving Testing is Not Safe (A parable)

Assume you cut your hand in the kitchen, then didn’t notice for an hour and had to be rushed to the ER. You do this 3 times per day.

You spend most of your time in the ER and very little time cooking. You want to fix that.

The improve testing strategy says “we’re going to cut ourselves all the time. How could we notice that so that we don’t bleed out?”

So we write something that will check every minute to see whether we’ve cut our hand in any of the specific places we’ve cut ourselves before. Of course, if we cut ourselves in the leg, we still don’t notice it and we end up in the ER.

And then we start checking our leg. Over time we are catching many our cuts in time to put on a bandage. We spend less time in the ER, but we’re still all covered in bandages and spend a lot of time looking for wounds.

Safeguarding would instead ask “why are we cutting ourselves 3 times a day? Why is this kitchen so unsafe?”

So we look and realize that the tilted counters are causing knives to slide off, people lunge for them so that the knife isn’t ruined on the floor, and then they cut themselves.

Safeguarding is to flatten the counter top.

Naming is a Process, Part 7: Intent to Domain Abstraction

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

New code is legacy code

My series about naming as a process is really about design. It focuses on design in legacy code. That has sparked people to ask about new code.

What about new code? Why not start with intent? I was taught to pseudocode or model, so that I could focus on the intent first. Then I don’t need all this after-the-fact concept discovery stuff.

  1. I always write new code with intent.
  2. I am never wrong about my intent.
  3. I’m never right either.

Continue reading “New code is legacy code”

Naming is a Process, Part 6: Does the Right Thing to Intent

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Naming is a Process, part 5: Honest and Complete to Does the Right Thing

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Naming is a Process, part 4: Honest to Honest and Complete

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Naming is a process, part 3: Nonsense to Honest

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Naming is a Process, part 2: Missing to Nonsense

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Good naming is a process, not a single step

After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!

Metrics: are we doing TDD?

A manager recently asked me how to measure whether the teams were unit testing. He believes that they are. He has heard strong alignment among ICs and managers. He also knows that the teams have no way to see if they actually are unit testing or how well.

He, like most people, asserted the use of code coverage as the core metric. Both total and per-commit delta.

I agree that we need some optics. I just think code coverage is a crap measure. Continue reading “Metrics: are we doing TDD?”