Error-driven Development?

So… it is a beautiful Wednesday and an idea popped into my head. Error-driven development😲😲😲!!! Did a quick google search on it and realized it wasn’t just me that has gotten the revelation at some point😒.

The unwritten consensus is that error-driven development is a pun on TDD and somewhat a methodology that enforces you to write errors and exceptions when things go or could go wrong as well as writing tests. Other ideas about the term range from the iteration of errors being a key force into the etymology of agile and how fixing and studying these errors over time could make you a better developer.

That was informative for me but I was however inspired in an unfamiliar direction.

And here are my thoughts:

Yes. Error-driven development should be a software development methodology. Which takes some ideas from other software methodologies such as agile, TDD, etc.

So, my thoughts are, it should not be an alternative to TDD. Rather, it is a variation. Here are some principles I came up with:

• Error-driven development is based on the principle that to disrupt is to forget. So on the successful pass of a test case, it forgets that the test case has been passed by invalidating it with the next most interesting insight.

• Error-driven development would eventually disrupt the original requirements rather than build or extend the requirement.

• Hence, there is a requirement in the beginning but the requirements are forgotten as iteration increases.

• Unlike the Agile methodology, error-driven development does not iterate or consider changes based on business value. Instead, it iterates based on the quality of insight. The most insightful knowledge gained from the last-passed test case is the point for invalidation.

• Error-driven development is then best suited for non-commercial products. And experimental or research-based project and programs of a long-span whose primary aim is to gain insights(It is amazing that software development which is science is largely concerned with commercial value and have less interest in experiments and hypotheses testing anyway).

So, let’s discuss. Is error-driven development worth a try based on these principles?