Software has way too many *-Driven Developments. But each framework is a can of inherited wisdom, and leaning on one usually saves rework. So I'm running the same trick on parenting — TDD, BDD, DDD, XP, all retranslated into how I'm raising my kids. Series starts here.
Software has way too many *-Driven Developments, right?
TDD (Test-Driven Development), FDD (Feature-Driven Development), BDD (Behavior-Driven Development), MDD (Model-Driven Development), DDD (Domain-Driven Design), TiDD (Ticket-Driven Development), CDD (Component-Driven Development), and now AIDD (AI-Driven Development) showed up. Honestly.
I get it, though.
I default to TDD on most of my own code. Write the test scenario first. Decide what "working" actually means before any code touches the file.
And when I'm getting an MVP (Minimum Viable Product) out the door I lean on FDD — slice it by feature, ship them one Done at a time.
So yeah, I get it. I just also think there are too many.
What is a software framework, really? It's a can with decades of someone else's hard-won pain packed inside. Stick to the can and you usually come out fine. Less rework. Fewer judgment calls per day. Easier code review.
I read ITIL (Information Technology Infrastructure Library) and PMBOK (Project Management Body of Knowledge) cover-to-cover at one point. Got the certs too. Most of the time I was just nodding — "yeah, of course, that's the right way." Doing the obvious thing on purpose ends up being the shortest path more often than not.
Cooking analogy: stick to the published recipe and you get a decent meal. The "earn the right to remix it by cooking it three times first" rule applies.
Try selling this to product folks or ops folks and it lands flat, kinda.
"Too heavy." "We don't need that around here." "We're shipping fine without it."
And in my head I'm going, do you have any idea how much battle-tested wisdom is sitting in that can?
But honestly, half of them are right.
ITIL never literally says "do it this way." It explicitly says: tailor it to your project, your team, your maturity level. Every *-Driven Development is the same — pick what fits the project size, the phase, the team. You don't apply the whole stack at full strength every sprint.
So when business folks say "we don't need this here" — yeah, half-right. The other half is they just haven't read the label on the can yet.
This is the real point.
Parenting has all the same structure.
Inherited wisdom is everywhere — parenting books, the preschool teacher, child-psych research, that one comment from the grandma down the street. Different shapes, same canned wisdom.
But nobody's filed it as "parenting TDD" or "parenting DDD where you respect the four-year-old's domain." In an engineer's vocabulary, the parenting catalog is barely organized.
So that's the series.
Take inherited parenting wisdom, sort it under engineer-shaped labels, and see what shakes out.
TDD → small, intentional failures so the kid learns from them. Failure-Confirmation-Driven Parenting.
BDD → Given / When / Then. "At this time, in this situation, if the kid does X, I respond with Y." Observation-driven.
DDD → respect the four-year-old's domain (dinosaurs still exist, elevators are alive). Don't translate it into adult words. Kid-worldview-driven.
Writing this out, I realize it's a pretty wild thought experiment. Some episodes will land. Some will completely flop. When one flops I'll write about why — that's also part of using inherited wisdom, I figure.
One more piece for the spine of this series.
There's that bit of folklore — when my wife asks "which one looks better?" while we're shopping, answering "either one's fine" or "they both look great on you" actually drags the trip out. Sitting next to her and worrying about it together speeds it up. (Source: I forget. Some study somewhere, I think.)
That's pair programming, basically. That's XP (Extreme Programming) in spirit. One person staring at the screen alone goes slower than two people staring at the same screen. The output isn't dramatically better — it's a little better, and it feels noticeably more satisfying.
Same with parenting, I think.
"Figure it out yourself" is a real option. But sitting next to my kid and worrying with them about the same thing speeds up their decision-making, honestly. And it updates me at the same time. It's not one-way teaching. It's pair programming.
XP-style — kid and parent struggling together, growing together ─ that's the "parenting framework" this series wants to import from software methodologies. That's the whole theme.