Accdient-Driven Development

Real-World Software Development Method — ADD

Forget TDD,BDD, or DDD

As an experienced developer, I bet you must know (or heard) TDD, BDD and BDD, so I’m not going to explain what they are.

1. TDD: https://en.wikipedia.org/wiki/Test-driven_development
2. BDD: https://en.wikipedia.org/wiki/Behavior-driven_development
3. DDD: https://en.wikipedia.org/wiki/Domain-driven_design

Maybe every development team is claiming that they’re using one of the methods, at least during the interview or in PPT.

My question is: how many teams are ACTUALLY following them?

Take TDD for instance, it requires the following sequence of steps

• Add a test
• Run all tests and see if the new one fails
• Write some code
• Run tests
• Refactor code
• Repeat

As far as I can see, in most of the teams, test cases do not exist at all. Sometimes there are some test cases which were built 2 years ago, but the latest release was published last week!

In real world, it is very rare to find a project/team where test cases could be built and up-to-date together with the latest changes.

“Test Driven”?

Sounds like a legend.

Don’t mention BDD or DDD.

Too many projects started implementation without anything from PM or BA or anyone. What the dev team had was just a vague idea. Nobody knows behaviours.

And most of the developers don’t want to be involved into early requirementss investigations. They don’t care about DOMAINs, because “that’s the job of architest/leads/managers”. Domain knowledges were asked again and again when different developers reach to relevant parts.

What on earth is the best methodology?

My answer is: ADD.

What does it represent “A”? Automation?!

NO, ADD is

Accident-Driven Development

Yes, all the developments were driven by accidents!

Obviously, all the defects are all accidents. Dev team has to fix them, as KPI requires every one in the team.

What about a new feature? Not suprisingly, it is just kind of a huge colleciton of accidents:

• Accidental “Great Idea. Let’s do it.”
• Accidental “requirement changes”
• Accidental “architecture optimizations”
• Accidental questions like “can we support IE6?” or “can we allow users to …?”

No behavious, no domain knowledges … all accidents. So, no test cases for accidents.