This Train
Software is a funny business. The industry uses quite a lot of terminology from traditional manufacturing. You’ll often here us talking about “shipping”, “delivery”, “building”, “containers”, etc.
Except our goods have no mass. They ship around the world in milliseconds. Making another copy of each good is functionally without cost. They are malleable beyond any physical good. This yields behavior that is very different from traditional manufacturing and logistics. Apps on your phone update weekly, web apps update many times a day, even Curiosity, the Mars Rover that travelled 352 million miles away gets software updates.
Why not just wait until it’s “ready”? No software ever reaches perfect. It is impossible to predict every possible way users will interact with even a simple application. Even if we could, the combination of possibilities quickly becomes larger than is economically feasible to code and test for. Thus software is an iterative business. Each iteration is an opportunity and a risk. It may sound counter-intuitive, but the more you iterate the faster you move and the less risk each iteration carries.
Suppose you take the train to work and suppose it’s the only way to get there. Now imagine that there is only one train that leaves for work per day at 8am for all commuters. What would happen? Nothing good. The train would have to be huge to accommodate all the commuters in your city. If the train had a mechanical breakdown the businesses in town would grind to a halt. Early birds would have to sit around the train station waiting. Late risers would show up looking disheveled having rushed out the door trying to make it in time. Being late would mean missing work and possibly losing your job so pushing and shoving would ensue. The train may be held for VIP passengers who *must* be at work.
This is what happens when your software only updates every month, quarter, or year. The software release train is late, commuters are poorly served, some of them forgot their stuff because they were running late and any failure is a really big deal.
Fortunately, mass transit doesn’t work like this. Trains hopefully come often and missing a train is only mildly annoying. If you are running late you catch a later train, if one breaks down another will be along soon.
Software on a continuous delivery schedule gets delivered faster, better, and cheaper. If the software release train leaves every few hours, features go out as soon as they are ready. Missing any given release is no big deal. If something goes wrong with one train you can take it out of the system and let the rest keep on moving. Keep the trains moving, and let everyone get to work.
Make sure to check out the other the blog posts from Gain Compliance, and follow us on Facebook.
