Comment Driven Development (CDD) is a methodology that is catching on really fast in the development community. CDD is actually not something new, teams have been practicing CDD for many years, and some might not even know they were doing it. CDD rests on
solid design principles like DRY (Don’t repeat yourself) and YAGNI (You aint going to need it). Some spells out the acronym as Comment Driven
Design - to emphasize the impact the approach has on your software design.
CDD is a technique based on searching the web ("Binging") for the solution to your specific problem, copying and pasting of the code you find and then utilizing the power of modern IDE's like Visual Studio to keep commenting out code until the application runs.
Fundamental for the methodology is also the rapid shipping of a "working" build to customer to test. The idea is to catch errors really late in the process and give the developer the freedom to be agile and do more searches for the parts of the solution that yet hasn’t been implemented.
CDD can also be coupled with TDD - TDCDD, where you search for code for the unit test and then comment that code out until the test doesn’t fail.
Some in the CDD movement have also suggested combining DDD with CDD, but concerns of a resulting anemic domain model have been raised.
This video gives a short introduction to Comment Driven Development.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.