There’s a lesson I learned a long time ago, and which I still find useful: deploy first, build after.
Many years ago, when I was working with Mat Wall, we were building a system which, er, did something. I can’t remember exactly what it was, but I think it probably involved an FTP server, which gives you an idea of how long ago it was. Mat and the team worked in the order of weeks to build this thing, and then when we came to deploy it, it was very painful. We realised it was designed to work, but it wasn’t designed to be deployed easily. Deployment involved far too many people, required us to jump through too many hoops, and we came to regret some of the key design decisions we’d made.
One lesson we took away from that was to always build a “shell” first—that was what we called it. We learned that we need to build the application in its absolutely simplest form, with no functionality beyond some basic “hello, world” capability. This was the shell. And we would make sure we could deploy this shell. After that the work was to enhance the shell with more and more of the real functionality, and all the while we were able to ship incrementally more complete versions of the product. We could be pretty comfortable that there would be no nasty surprises as we got towards the final crunch deadline.
In other words: deploy first, build after.
In the many years since then I’ve mostly forgotten the specifics of what happened, but again and again I’ve found the core idea to be valuable. “Ship early, ship often” is a related and often-used phrase, but doesn’t quite capture what we learned that day—“early” can easily be postponed until we think the client or end user should see version 0.1. That might be weeks after our project has started. If we build in—and prove—deployment from the beginning we’re in a much better place as momentum gathers, and always able to concentrate the core work.
niksilver.com 