What a glorious analogy, folks!
The most vulnerable time on a football bitch is mid-pass. The ball is slicing across the grass away from one player to another. In that time anything could come in to disrupt: bad surface, weather, and worst of all — another player from the opposing team.
This is a nice metaphor for software development.
This “ball rolling away” vulnerability exists in the software world too. It correlates to that bit of time when your software hasn’t gotten to any users. The bit where it sits, finished, on a dev machine.
#shipit is a bullshit West Coast of America phrase for “don’t be exposed,” or “don’t be vulnerable.” It’s a marketing term to ensure that devs are coerced into shipping constantly. From a dev perspective that’s really exciting and a break from what devs of the olden days were used to, but from a business perspective it ensures that there’s little or no vulnerable code, which is hugely beneficial to the company.
All code should be accessible by the system you’re building. If that means the code should be exposed to user input in the live environment, great. Sometimes it means putting it on a QA server, or in a queue for a deployer. Either way, it’s not sitting on a folder on a laptop doing nothing, or in a holding pattern until the dev feels it’s “just right.”
Of course, there are isolated times when not shipping matters. But in general, the #shipit culture is all about making sure that you’re not the same as a football player with a ball rolling across the grass away from you at all times.
The ball rolls away from a football player, but code sitting on a desktop does the same thing — it’s merciless against updates to the system in the live environment when other engineers ship their code. It’s also not doing anything for the customer. And that’s the main reason you become a developer: to build things for people.