JFDI Deployment

One of the things which small and startup companies often do so much better than large, established ones is encapsulated in this four-letter acronym: JFDI. Just Fearlessly Do It. (You can exchange your own 'F' if you prefer).

The reason you JFDI so much as a small company is because the alternative is not getting paid. If the core API doesn't get deployed tonight, then neither does the new version of the sales application. If the sales application doesn't get deployed, the big client doesn't sign the contract. That new version of the core API might have bugs... but at least if it goes live, the company has a fighting chance of being around long enough to fix it.

When you get big, the pressures around such things decrease. The software release you're preparing represents 5% of your projected revenue, not 50%. Even if it doesn't go live, you've got an experienced negotiating team who can smooth it over with the client, rather than someone who tore their hair out just to get whispers of a contract on the table. And suddenly you find yourself doubting - not wanting to touch the core API which drives all of your services, just for the sake of that 5% which you might not lose anyway...

This is where you get to the development team that doesn't JFDI. The team that would rather create another CI, another wiki page, another test environment - anything but put their code up on the live server and switch it into production. The team that wants deployment gates, and extensive manual testing, and even after that still find some excuse why they can't deploy tonight.

The irony here is that deployments at this stage of a company ought to be at their lowest in terms of risk. The important distinction between a JFDI team and a bunch of cowboys is that when something goes wrong (and in the chaos of a startup, it goes wrong often) you learn from your mistakes and establish procedures for dealing with them. Code starts getting reviewed before it goes live. Tests get written for key methods. You use continuous deployment to blue/green environments rather than overwriting binaries using a local development build.

An important theme running through all of these is that they don't make your deployments take any longer - if anything, there's less work involved than the wholly manual approach. What you're doing is managing risk; understanding that as a core software component drives more things, then the chance of a rogue deployment taking everything down needs to reduce in proportion. Everybody wants to do this, but the thing which keeps a software team moving is to automate things, to bake them into your procedures such that they become another thing the computer checks for you before you go live.

And that's how you keep your JFDI attitude even into a large company. When a single click on a button in a CI/CD system checks against every potential deployment problem you've ever known, sets the checklist green and says "good to go", and you're taking advantage of this regularly enough that deploying software barely registers as a "thing" any more, then you know you've got there.

So... are your deployments a nightmare? Do you find yourself or your team spending days or weeks moving from staging to live? Then maybe it's time to think how you move closer to that model, and the next time some key component of your architecture needs to go live... JFDI.