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!

Architecture – Scaling Design

My position on architecture is different from most peoples’. My view works really well at scale (much better than the traditional view, in my experience), but it is very different.

I start with one traditional definition of architecture: any decision that would be costly to change. However, I also know that I (and those on my teams) learn quickly. Every problem that I found difficult at some point has later been found to be easy…once we learned more. This gets me to my final definition.

Architecture is any decision you make that you are not yet smart enough to be able to change on a whim.

The best large systems have no architecture, under my definition, at all. Continue reading “Architecture – Scaling Design”

The No Mocks Book

Recently on twitter, Clayton asked for a good book about unit testing without mocks. I don’t believe such a thing can be written, so I’ll try to write it in one blog post. First, here it is in one sentence:

Mocks are a smell. They tell you that your code depends on some semi-related part of the system. Rather than work around the design defect, fix the design.

The trick is figuring out what smell you are observing and how to “fix” it. Basically, what alternatives exist. Down the rabbit hole we go. Continue reading “The No Mocks Book”