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!

Fixing Legacy: What Should I Blow Up First?

Another good question came over the wires at work. My reply grew too long and I figured more people would want to see it. Besides, this way I can blog and call it a legitimate business activity.

Problem statement: what patterns and strategies work for choosing when and what to refactor? Does this change at scale? Continue reading “Fixing Legacy: What Should I Blow Up First?”