Comparing Food Trucks and Software Development
Over the summer R/GA had a bout of what doctors call “Food Truck Fever”. Every day a new food truck showed up in front of our building on 39th street serving everything from Koren BBQ, homemade Chinese dumplings and artisan ice cream. Every day the trucks were greeted with a long line of hungry R/GA’ers ready to scarf it down. One of those days after work I went to the Highline beer garden and for dinner I had an $18 Lobster roll sandwich not much bigger than an iPhone served from (you guessed it) a truck.
What’s interesting about these food trucks is they skip one of the most important parts of a restaurant, the location. Actually judging by the quality of food in Times Square I would argue that the location is more important than the food. By not being committed to a location the food truck can just concentrate on the actual food they are selling. They can also start up with a very minimum investment and can easily switch what their product is. This means they’re able to start a new truck with very little risk. I can image the conversation going something like:
Person A: “You’re crazy, no one is going to spend $18 on a small lobster roll sandwich”
Food truck: “Well I’ll give it 3 months and find out. If it doesn’t work maybe I’ll also sell crab cakes or I’ll just turn this lobster truck into a hot dog stand.”
I am struck by the similarities between these food trucks and building software. Where software lives (its location) dictates almost everything about it: what language it’s written in, what tools you can use and what the procedure to deploy to production is. Cloud based application platforms like Google App Engine, Amazon AWS, and Azure allow your software projects to operate more like food trucks. They have very little upfront cost, allow you to use the latest development tools/frameworks and you can deploy right to production. So your project can be built very quickly, change on a dime and be up in a stable production scale environment in minutes.
Not all software projects are food trucks. The great Peter Luger’s Steakhouse could not exist on wheels. Usually new projects that aren’t fully established yet or smaller projects are perfect candidates. Without this new ability to quickly spin up an environment, applications are typically built on older, established environments that support other things. Having your app run in the old steakhouse could drastically impact the amount of time it takes to get things done.
Here’s another fake conversation for you:
Client: “You’ll need to parse this XML service and store some data into a new DB column”
Food truck project: “Well let me just install the latest and greatest in XML unmarshalling technology here and store the data in a new class property where my persistence layer will save it to the DB automagically. It will be in production at the end of the day”
Steakhouse project: “OK well the environment only support SAX 1.0 and upgrading to anything else may break other projects running there. So parsing the XML will take some time as well as writing the code to properly store and retrieve the information from the database. Also I’ll need to contact the DBA and explain what the new column is for, have him generate the scrips to add it and have him deploy that in our environments. We’ll then schedule the change with the QA engineers to be part of their bi-monthly release and if everything in that release passes we should be up and running in November.”
So when starting development on a new software project be more like the food truck as much as possible.