Scripts like that need to be able to recover from a very wide range of error modes caused by subtle differences in how target machines are setup - or at least fail in a reasonably obvious way.

Writing such a script is significantly more time consuming than writing a README, and for it to be worth the effort, it should be expected to save a fairly high multiple of the time it takes to write, debug and support. For GitHub, that multiple is definitely very high, for Patrick, it might not even be greater than one. YMMV.

That's the background on a couple of tweets I've already sent today - part of a 56! post sequence (3/4 done, I'm splitting it up a bit).

https://twitter.com/alister_b/status/636563590288437248 - 29/ If I start work and have to spend 3 days just getting the dev site running locally - we know the live site is also a pile of crap

There's a plenty more of along similar lines about recruiting, interviewing, and the working environment - both for people, and the code.

When I'm done, I'm putting them all together in a blog post with some extra thoughts as well.

I like this idea a lot. We're going to steal it.

Very similar to this, I like to say that automation is documentation. Of course, actual documentation is better, but compared to no documentation, a script or automation or test is better than nothing. I used to do this just because i'd forget how to do something so I wanted a written down example of it, and then I make it into an actual program, and then I automatize it. You wouldn't believe how many people end up depending on these crap little examples. And of course READMEs in every directory in a tree that explains what everything in that directory is and what it does.

Yup, it's a great idea! In all of our applications we have a build-dev shell script that builds the application for development purposes.

New developers day 1: vagrant up; vagrant ssh; cd /path/to/app/on/vm; ./build-dev

And they're ready to go.