NDD (Naming Driven Development): I Wrote a Guide Book on Software Review!

I wrote a book. A Kindle book. $10.

👉 Amazon: "Nearly Everything to Check in a Software Review: Review Standards for Software Built with AI through NDD (Naming Driven Development)"

Why a book?

For the young engineers I care about.

I wrote the Software NDD Review Standards and put them on GitHub. But I knew it was a stretch to ask a beginner to digest nearly 1,000 lines of plain text written mainly for AI.

"I should at least explain it with figures..." That was the thought. Also, I started it on a bit of a drunken impulse. (lol)

The important stuff is right here in this post, and the Standards are free on GitHub. If money is tight, you don't need to buy the book.

But if you're an engineer with high aims, who lets AI write the code but still wants a firm grip on what matters, I'd be happy if you picked it up. It's on Kindle Unlimited, too.

What is NDD?

Naming Driven Development. This old guy came up with the name.

In one line:

People put their soul into names and leave the rest to AI.

In other words, it all comes down to this:
"In the beginning was the Word, and the Word was with God, and the Word was God." (John 1:1, King James Version)

A while back, I wrote that "this is the era of SDD (Specification Driven Development)!" SDD lasted about six months.

Today's AI writes better specs than this old guy, who has written specs for 20 years. There's almost no job left for humans in writing specs. So I went back to the old to learn the new.

1. Over the years we had machine code, then structured programming, then object-oriented, then functional. Plus MBD (Model Based Development), TDD (Test Driven Development), and more.
2. Each step was the same thing again: "The details are a pain. Computer, you do it." "I'll think harder about what really matters!"
3. Then, around 2026, AI took a big leap.
4. So in the end, what humans do comes down to just this: telling AI "For what purpose, for whom, what, and how do I want it?"
5. Then how do we do that well? "Say exactly what you mean, in words that both AI and people can understand, clear and with no room for misunderstanding." That's about it.
6. So from here on, the value is in polishing each word, one at a time.

From here on it's just a book introduction. If you already get it, feel free to stop reading.

What's inside?

Roughly all the viewpoints of a software review: specs, design, code, and tests.

The Standards are mainly meant for reviews done by AI. This book explains, with plenty of figures, the knowledge a human needs to do a review.

Is it worth it?

Depends on you. The Standards are free, and if you feed them to AI, you'll get pretty decent software most of the time.

But here's the thing. Knowing the principles and not knowing them makes a huge difference.

When AI hands you something, can you say in one line, "Isn't this an OMPV violation?" (OMPV is the principle "One Meaning Per Value.") AI will write code for you either way. But the people who can say it get far more out of AI.

This book is for being able to say it in one line.

I wrote it for:

• Anyone who is unsure what to point out in a code review
• Anyone who has AI write code and wants to judge whether the result is good
• Anyone who wants the principles of design in one place, in words and figures

Closing

This book isn't something this old guy cooked up on his own. It's the blood, sweat, and tears of the great engineers who came before us, rearranged for the age of AI and turned into figures.

It'd be great to see more people saying, "Software development is fun, let's talk about it!" I'd love that...