A suggested approach for your next project: RDD — README Driven Development

Side projects are an amazing thing.
We learn, experiment, and collaborate with the world through them.

Most of us probably approach side projects by building them, function by function, feature by feature, and they come to be.

However, with my recent project npq I wanted to do things a little bit different. It’s something I thought about for a while, and I had in my head the overall requirements for.

README Driven Development

A project’s initial commit is usually boilerplate code, framework, .gitignore’s what not. The other side of the spectrum is where developers complete a great milestone in private, and then push all of it as an “initial commit”.

README’s are usually an after-thought.

Not this time though.
My initial commit included a documented README with the features I want to support and the expected user interaction with tool.

2 months of iteration, and 22 releases later — and the basis I laid out in the initial README are the same.

You already know that the only constant thing in software is change.

Requirements change, features are added, and things might overall take a pivot.

Still, I find RDD a bit like TDD — it forces you to think about the overall result, without tying your hands down on implementation details.