Launches can bring a flurry of emotions and be quite the adrenaline rush if you’re at the steering wheel of the operation. As developers, we feel a lot of pressure to pull off a perfect and blemish-free launch for our teams and clients, but we know that it isn’t always possible. From experience, we have learned that there are few things more complicated than a launch and, therefore, a lot of planning goes into making it happen.
Timing is everything when you want the kickoff to go smoothly. Make your plan as detailed as possible, foresee every potential mishap, and perfect the solutions before they happen. But no matter what you do, you should also know that shit happens. As the great Chief of Staff of the Prussian Army Moltke once put it, “No battleplan ever survives first contact with the enemy.”
Here are some things you can add to your list of foreseeable hiccups and annoyances, although every launch will come with its own set of unique challenges.
1. People saying “Flip the switch”
Nothing screams miscommunication more than when someone on your team blurts the words, “Just flip the switch already.” We know it’s not that easy, and your team and client should understand that too. If the individual saying “F*** it, push it live” plays a crucial role in your launch, it’s best to sit them down before the launch and explain that there are many switches…and levers…and buttons…oh, and tripwires too. If they are under the impression that all it is going to take is flipping a switch, you’re setting them up for disappointment when anything but the perfect launch happens. It simply doesn’t work like that.
2. People asking “Are we there yet?”
No one likes an over-anxious or impatient manager checking for updates every five minutes, but no one likes to be left in the dark either. It doesn’t always help having a reminder to move faster or give updates when you are mid-launch and don’t have any to give. To stay on the same page, set up a plan of communication that accounts for several check-ins at different times during the process. It makes you accountable for reports and updates that are either free-and-clear or composed with solution-driven answers to newly developed issues. Of course, we’re hoping for the first.
3. Underestimating downtime
As I mentioned before, timing is everything. Some strategies out there still call for downtime after certain code alterations. While it is not totally detrimental to your launch, you should keep in mind the impact of those offline breaks on the timeline of the launch and the users of your product. Accurately reflecting the true amount of time it will take you to implement the change is going to save a lot of headaches down the road. Even better, if you overestimate the required time for a task, you will be a hero by finishing it sooner than expected. Win-Win.
4. Concurrency and migration issues
Most data structures enforce some sort of data concurrency and data validation, which is awesome. However, that means sometimes your most well-thought-out migration strategies and plans don’t take everything into account. In this case, you’ll need to have a firm understanding of your data sources before jumping in. The worse thing you can do is try to manually fix a data issue without being fully versed in that data and what rules it should be following.
5. THERE’S A BRAND NEW BUG ON PRODUCTION!
Take a breath and a step back. A new bug can alarm you and your team, but remember that you just have to identify your problem and find a solution. Don’t count the launch a defeat yet, it could just be a small issue with data, permissions, or configurations. In this case, take a moment to figure out how to resolve it quickly and adjust back to your timeline. In other cases, when the issue is critical and requires a code fix, it could be time to break out the rollback.
6. The need to roll back
You won’t think you need this plan, until you do. Some unfortunate luck and buggy codes may force you to go back to work on your product framework. Ideally, you will only have to roll back once in a blue moon. When this happens, you must react quickly and skillfully. A mechanism should be in place that will change production back to the original with as much efficiency as possible. In this case it really should be a switch to flip.
7. Ummmmm…did the server just crash?
If you have to ask the question, it most likely did. For most companies, your production base and your test base are vastly different. Even if you spend time making perfect clones, your production system will almost always be exposed to loads, data sets, and scenarios you haven’t actively tested.
In this case, watch your server. Make sure that your architecture for launch is either automatically scalable and/or you have performed accurate load testing. Your tests should use real user data – yes, throw commas in fields that shouldn’t have them and hit submit forty times because that’s what real people do. This will aid in creating a lessening impact on your server when your product is hit with the phenomenon of real users.
8. Staying late
Clear your schedule. Even if the deployment goes smoothly, launch day can take up a lot of time for the teams in charge. You should babysit your application for a few hours after a launch, watching logs and database transactions and server vitals. Make sure users are actually doing what they need to do and that the new features are working. Be ready for bug reports and questions from users.
If you’re lucky, you’ll be able to get other work done while your website healthily chugs along, but you definitely don’t want to commit to offsite meetings or a dentist appointment, and you should probably click “Maybe” on any Facebook events for that night. A freshly launched website is like a newborn baby and needs your constant attention.
If you do end up staying late at work, make sure you get the company card before your bosses leave. It’s universally understood that beer and pizza is the standard reparation.
9. Getting all hands on deck
A launch is a team effort, even if you’re the only person in the driver’s seat. If something goes wrong and you can’t get ahold of the right person fast enough, you’re going to have a bad time. Before your launch, make sure you identify everyone that has a stake in the launch and get their contact information. Ideally, you can all be in the same Slack channel or group chat while it’s happening. Any developer who has code going live must be reachable, along with project managers and product owners. You even want to make sure you have the phone number of the hosting facility, in case you need one of the techs to go cycle power on your server.
10. A well-deserved celebration
If you’re launching a website, this is probably how your company makes money. This is probably how everyone gets paid, and how the whole operation stays online. It’s too easy to quietly launch a new project, verify that everything is working well, IM your boss that the deed is done, and then move on to the next task. Plus, that’s so lame.
When you launch a new website or a new version of your application, you’ve formally put the hard work of your team out into the world. Take time to celebrate that. Reflect, congratulate, and be proud of the work you’ve done together. Not only is it rewarding, celebrating a rollout reinforces the notion that a successful launch is an important event that deserves all the attention and hard work it required.
Ultimately, the science behind launches operates as a delicate balance between having incredible patience and pulling your hair out, all in the name of a successful launch. When your product goes live you will feel an insane amount of relief, excitement, and fear simultaneously — but try not to fret too much.
Remember, even launch veterans experience mishaps too. The best we can do is learn from our mistakes for the next launch and find a solution in the meantime.
What are some of your best launch stories? How does your team handle launches and what tips can you offer? Join the conversation in the comments!
This article also appears on our Medium Publication. Recommend it to others and follow us for more news and notes.