I used RDD to develop a small command line utility this morning:
github.com/dayvonjersen/linguist/tree/master/cmd/l
go get github.com/dayvonjersen/linguist/cmd/l
RDD isn’t a whole big methodology or anything like that. You just write the README before doing anything else.
…I mean I had a bunch of stuff and some solid ideas first but whatever.
It’s kinda similar to Design Driven Development in a way, in that you defer to the specification when writing the code, but far less restrictive, at least how I used it.
By describing and explaining usage, behavior, and output before the thing is done, from the perspective of writing documentation for the user, you end up with a very clear set of things to do and how they should behave.
When you realized you missed something or need to change it, it feels almost natural to update the README right away to reflect the changes.
When you’re programming and considering a potential edgecase you’re uncertain about how to handle, you can refer back to what the README says to snap you out of that dangerous, delusional mindset of engineering overly clever solutions to invented problems.
Contrasting this process with writing documentation after the fact is like night and day: rather than making in-the-moment design decisions and trying to explain them later, everything is just logical smooth sailing.
If you’re coding up any sort of command-line utility, API, library or other such user-facing program, I highly recommend writing the README first.