Readme Driven Development
tom.preston-werner.com
Readme Driven Development
1–10 of 59 posts
Re: Readme Driven Development
#2This should be followed by an overview of what should be in a readme, as well as examples of good and bad readmes.
Still, good stuff. Just leaves a few questions.
Re: Readme Driven Development
#3This should be followed by an overview of what should be in a readme, as well as examples of good and bad readmes. Still, good stuff. Just leaves a few questions.
A good readme is a lot like a good manpage: http://rtomayko.github.com/ronn/
Re: Readme Driven Development
#4It would be nice, if we dont consider the fact that nobody reads README at all.
"A perfect implementation of the wrong specification is worthless."
The point of BDD is exactly this: bring specification to the scene, give it a first class citizen status, it becomes a live entity in the system, more influential than before. I don't believe Readme or any other document can be as influential as a Cucumber feature, for instance.
Re: Readme Driven Development
#5It would be nice, if we dont consider the fact that nobody reads README at all. "A perfect implementation of the wrong specification is worthless." The point of BDD is exactly this: bring specification to the scene, give it a first class citizen status, it becomes a live entity in the system, more influential than before. I don't believe Readme or any other document can be as influential as a Cucumber feature, for in…
From a "using stuff off of GitHub" perspective, the README file is front and center when you look at a project.
Re: Readme Driven Development
#6It would be nice, if we dont consider the fact that nobody reads README at all. "A perfect implementation of the wrong specification is worthless." The point of BDD is exactly this: bring specification to the scene, give it a first class citizen status, it becomes a live entity in the system, more influential than before. I don't believe Readme or any other document can be as influential as a Cucumber feature, for in…
When I'm researching new tools/libraries, the first thing I read is the README. If it's worthless, then it's a fair bet the tool/library is, as well, and I won't be using it by choice. After that, I look at the official documentation. If all it has is auto-generated API documentation, that's another strike against it. Then I look at the API documentation. The tests are somewhere way in the back after all of this.
Re: Readme Driven Development
#7I have a hard time thinking seriously about this, because all I can think of right now are those repos on GitHub that have nothing but a README file.
Re: Readme Driven Development
#8I have a hard time thinking seriously about this, because all I can think of right now are those repos on GitHub that have nothing but a README file.
They obviously haven't gotten to step two... writing the code.
Re: Readme Driven Development
#9As an example of a project that was written with RDD in mind (I wrote this while I was writing this blog post), see http://github.com/github/gollum. This is my notion of the scope and specificity that a nice Readme should have.
Re: Readme Driven Development
#10Seems that mojombo practices what he preaches. First commit by mojombo (from march 29, 2010) of Github's Gollum wiki reads "readme driven development!"
http://github.com/github/gollum/commit/c7875704971be998a5399...