It's funny how some traits in software development are always present, no matter how small the development effort. One of these is the ever-surprising difficulty of the first production deployment.
Last week, I updated the layout of this very blog. We had decided to add a couple of things, reposition something, update the fonts, and so on. With Posterous, all of the "advanced" modifications are a matter of editing the blog template—that is, a raw HTML and CSS file which dictates the layout.
As the old layout was not that far from the new one, I decided to start with the existing template and gradually evolve it to the new look. Obviously, the blog would appear horribly broken in between, so I set up a development environment of sorts: another blog on Posterous. I then copied the existing template to my fresh development environment, where I could upgrade and tweak the layout until the whole thing looked beautiful.
When I was content with the layout in the development environment, I copied the entire template back to production, i.e., our actual blog. And it didn't quite work.
Contrary to what I had assumed, not everything about the layout is determined by the template. A so called accent color is defined outside of the template, an innocuous tag caused the template to render differently if a standard header image was uploaded to Posterous even if the image wasn't used, the fonts were all quirky, and so on.
All of these issues were easily solved, but nevertheless a whole bunch of work popped up at the production deployment step, where I thought I was done save for a quick copy-paste. If the first production deployment caused so much unpredicted extra work in such a small project, imagine the consequences of postponing the first deployment in a large development project, where efforts are measured in weeks instead of hours.
So get that first production deployment out of the way as soon as possible, with just the smallest value-adding increment, and you can cross one major project risk off the list!