Die-hard fans of test-driven development advocate writing tests first, when no code of the actual program has been written. Their purpose at this stage is to serve as an (incomplete) specification of the program that also does not capture or express its actual semantics. To me, the described extreme case of TDD is meaningless, but recently I’ve discovered a real situation where one might want to write “code before actual code”. Let’s call it “deployment-driven development”.

The basic idea of DDD is that you always keep your program in a state where it can be deployed anywhere. This means you always start writing deployment automation code before anything. Want to work on a Python webapp? Instead of installing nginx and uWSGI locally, write a Puppet manifest or a Chef recipe first that will apply it on a virtual machine or a Docker container. It may even take less time to do this than to perform an actual installation. Need to add a database or configure log rotation? Update the manifest and redeploy. As a result, you’re always dealing with a software that is ready to be deployed anywhere and is not confined within your development machine.

There are a number of advantages to starting even the small projects with server automation first. When the product will be ready to go live, there will be many less checkboxes to go through in pre-launch checklist, and many less last-minute surprises. Exposure to deployment makes you think about the system architecture of your product at a very early stage and grow it as you code. You are always spawning an isolated machine to run your code, so library dependencies from different projects won’t interfere with each other.

What’s not to like about it?