I started a little project this weekend. First, I found a project on Github that will serve as a foundation, and then I’m going to customize and extend it a bit to do what I want. That’s beside the point.
At Cheezburger I kept a wall of sticky notes with bits of wisdom I have learned over the years. This project gave me an opportunity to walk the talk and live by one of these little bits of wisdom I’ve often shared with others:
Ship First, Develop Second
What that means is that when starting a new project, just write the “Hello World”, then setup deployment process to your production environment, and ship it. Now, the full pathway from your idea to your keyboard to realizing potential customer value has been paved. Then, from here on out, things are simple: you’re just doing incremental updates and deployments.
The original sticky note from my wall.
Now, I don’t mean to suggest that you start by creating a robust production environment that can handle massive loads of traffic with redundancy, backups, recovery and monitoring support. I’m just saying that you need to get your code live to the world. You want to create something that is apt for the age of the project.
In my case, setting up deployment meant creating an micro EC2 instance, twiddling some DNS settings, configuring a git remote, and installing a handful of packages on the new instance, so that the app would run. That took me a few hours because I was trying some new things I hadn’t done before, but all-in-all a very modest investment to avoid common pitfalls. (If the project goes smoothly, then I’ll set up continuous integration, monitoring, etc.)
What are those pitfalls? Well, this wisdom is contrary to another bit of Lean wisdom: delay effort, work and decisions until the last responsible moment. In other words, that principle would say that setting up the production environment before a line of code has been written is wasteful. Yet, there are two mistakes I often see made, and this helps avoid them.
First, developers often spend a lot of time writing code before showing it to potential users. Part of that problem is that there’s a giant barrier between the work and the users: the setup of a production environment. This approach puts you a more natural position to show your work and get feedback because it’s ready to be shown from day one.
Second, developers rarely develop as incrementally as they could. Again, this approach positions you in a really nice way to make small incremental changes, bit by bit.
All-in-all, my point of view is that I’ve seen too many developers waste too much time by writing code that never sees the light of day, or when it does see daylight, doesn’t meet the users’ needs. Generally, I try to stay lean and avoid waste, but this small bit of premature effort seems worth it.