#spreadsheet driven development

At DoctorC we like to move fast, but not break things all the time. To do this while maintaining a break neck speed of a startup, we came up with a methodology which we use to experiment with new features. Neehar christened it SDD (Spreadsheet Driven Development). We kinda arrived at it while following one of the tenets of the gospel of Paul Graham - “Do things that don’t scale.”

Here is how it works -

Someone in the company pitches an idea for a new feature.

As with every other idea in a startup, we aren’t sure whether its gonna be useful or not.

The quickest way to experiment is to do it - manually.

Create a spreadsheet (a google doc so its easier for collaboration) which basically behaves if the feature was developed completely. Use it with live data. More often than not its just mocking what a couple of tables on the database would look like. The business logic is just a bunch of humans updating it by hand every time.

Test and iterate on it. Tweak it to fit your needs.

Decide whether you want to roll it out with full support from dev team. If not, then keep the spreadsheet as an archive of your record of your experiment.

If yes, then forward the spreadsheet to the dev team and they use it as the design doc for the feature. No requirements doc needed.

Profit

I want to add that the manual part is really painful and slow. It makes people who have to do the work complain, grumble and generally not be in that good of a mood. But the benefits of it are phenomenal. We can change our experiment on the fly, find out what is useful and what is not. It enables us to have a solid view of what the feature should look like from end to end. This keeps the dev team focused and moving fast.

Most of our experiments run for 2 weeks before we make a decision. And since we run more than one in parallel it helps us test out a lot of stuff without bringing everything else to a screeching halt.