Readme Driven Development

When I worked for a consulting company, I found myself constantly thrown into a world of other people‘s opinions. This is especially true when discussing development practices. The problem with “best practices”, is that they are different for every company based upon specific needs, and don’t always apply everywhere. For these larger companies, test driven development seems to be a popular practice, but for my smaller personal projects, I have learned to adopt readme driven development.

RDD is the practice of writing your application's readme first, and designing the application around that document. This allows you to focus on the functionality of your app first, and get a better understanding of what technical challenges will need to be overcome. This will have the time saving benefit of less code refactoring, and better overall design. In addition, this method of development will make feature creep less of an issue - as long as you lock your readme file before you start development. If a readme file is written well, you can even distribute it to friends or other developers, and they will be able to spot usability issues before production begins.

Programmers hate writing documentation - I get it, but without a clear direction, a programmer also wastes time. If you have to change or refactor code everytime you change your mind about a feature, you‘re software will be delayed or shelved. Also, if your anything like me, you are most excited about your project when you first start, and when you’re excited about something, writing a document is not so bad.

For large projects this method won‘t always work, but larger versions of this methodology are used everyday. A good example of this is Game Design Documents. This is done on quite a larger scale than a simple readme, but the principals are the same. A document is drafted with the intent of being revised until the ideas are solid, and the flow of the game makes sense. Once the game starts production, however, the document is locked and distributed to the entire team as a development reference. This can sometimes turn into a waterfall nightmare or an agile meeting extravaganza - that’s what you want to avoid.

So give it a shot. Write that Readme file first, and stick to it. Chances are, you will finish your project faster, stay excited about it longer, and when your done, you won't have to go back and write that document you hate so much.

comments powered byDisqus