
Readme Driven Development - shawndumas
http://tom.preston-werner.com/2010/08/23/readme-driven-development.html#
======
ggchappell
This article looks like it has some good ideas in it. But the practical side
of me thinks it would probably only work well in the context of small- to
medium-sized projects whose users include few, if any, technically ignorant
people (libraries, command-line tools, etc.).

Maybe (?).

Also, this has been submitted & discussed before:

<http://news.ycombinator.com/item?id=1627246>

------
rhizome
This is a circuitious restatement of Fred Brooks' technique of writing the
documentation first and having that be the framework from which the features
of the code progress, such that usable code is a foregone conclusion if there
is nothing in the software that is missing from the documentation. Transposed
from mainframe manuals to README files, natch.

~~~
pjscott
The difference, according to the article, is that the README should not be too
detailed, so as to prevent the process from turning into a waterfall model by
another name.

~~~
rhizome
It's a distinction without a difference when that distinction is merely to
include less detail. I don't consider doc-driven implementation to imply
waterfall, though. It's just as close to BDD.

------
bediger
That's great: I'd love to see more "enterprise" software written this way.

But isn't this just a plea for a small design document up front? Not a fluffy
mountain of "Word" format piffle, but some plain language explanations.

------
erez
Am I the only one who's been jaded by all those Buzzword-driven
"methodologies"? If anything, its development-driven-development. Anything
else is practices.

------
pkananen
I'd say we should take this a step further, and substitute value (specifically
business value) for README.

~~~
arctangent
This is the approach taken by agile methodologies.

------
swah
This is from Aug/2010.

