Conclusively demonstrating why you should listen to others…
“Should” we follow a plan or test hypotheses? I don’t see these as opposites, but I do see an underlying system that tends to result in a continuum. And there’s a missing third item. Let’s explore.
Along the way, we’ll discover a primary source of technical debt, of organizational mis-alignment, and what we can do to solve that root cause.
Continue reading “Plans vs Hypotheses”We needed to improve quality. Not just once, but all the time. And we needed to do it across over 100 teams, each of which had a different context and different quality problems. The problem that impacted the greatest number of teams impacted only 6 — and more than 70% of the problems affected only one team.
No central plan could help with either of these. We needed a systematic solution, a strategy. But not a central plan. We needed a practice, a habit — something that combined funding with problem fixing, while reinforcing local ownership.
That’s when we invented Safeguarding. That was more than a year ago; teams are owning their quality and actively making things better.
Another company had consistent risk aversion. Commonly, people identified the option with the highest expected value…and then did something else. In that environment, the personal costs of even tiny failures were too high. So everyone consistently chose the lowest-risk option, even when that was a guaranteed bad outcome. Psychological safety was totally missing. And yet each relationship was different, with different risks.
Safeguarding was also an effective strategy for creating Psychological Safety.
Continue reading “Safeguarding – Culture is a Process, not a Single Change”
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.
Not all refactorings are created equal. Some get used a lot more than others. This is especially true with highly-indebted code. There’s a reason for this. Sets of refactorings are commonly used together to solve classes of problems, and some problems are more common than others. If you are learning to refactor, learn your tool in sets.
The most important set to learn are the Core 6 Refactorings, plus 3 critical utility functions.
These 9 operations will allow you to do the most important part of working with indebted code: read by refactoring. Fluency in these 9 is all you need. Continue reading “The Core 6 Refactorings”
Programmers are familiar with the DRY principle: Don’t Repeat Yourself. That’s great advice for production code. But tests are different. For tests, use WET: Write Explicit Tests. The two lead to different results. Let’s look at an example. Continue reading “WET: When DRY Doesn’t Apply”
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!
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.
We are not fucking agile. Stop talking to me about Agile.
—Boss of one of my mentees, in a 1:1 career advice session.
Though I wasn’t in the room at the time, here is my response. Feel free to use it.
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!
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!