Launch Protocol
By Bobby WhitmanLaunching a large web site or web application can be tricky. And, to be quite honest we rarely do it right. I always envision it going something like this:
1. We complete the last list of tweaks and changes from the client.
2. The site is tested across various platforms and browsers with different browser and system settings. Any issues that arise there get fixed. We also ensure that all XHTML, CSS, and RSS meet W3C standards.
3. Code is cleaned up, documented and minified if necessary, then frozen. This means for the next two days or so we continue to use/test the site but code is NOT to be touched.
4. If all is clear we push the site to the live server, but hidden under a subdomain. Run through all functions in its live environment. If there are problems, they are fixed and we start over again at the code freeze step.
5. If we no issues are found, a simple DNS change and the new site is live (instantly and without downtime).
Unfortunately, it does not seem to happen that way. As much as we insist that this is the way to go, clients demand otherwise. There is always a rush at the end to get more and more client changes complete and still launch on an arbitrary date that the client chooses.
But, this is bad for everyone. This single most important thing for a web site or web application is that it is error free. And, the more we rush at the end, the more problems we have. New issues quickly arise because a rushed programmer does not consider every consequence of their changes. This means introducing bugs at an increased rate, many of which go undetected until after launch.
Two things that I would like clients to understand:
1) You can control launch date OR state of site at launch, not both.
We’ve had clients insist that we launch on Friday, then deliver a list of revisions Thursday evening at 8:00pm. This doesn’t work. If you insist that we launch on a certain day, then we drive what items get implemented prior to launch.
2) Remember, launch is not the end.
Give us a list of changes you’d like, but trust us to prioritize them. If we’re nearing launch, we’ve probably spent several months understanding your organization and your goals for the website. Let us decide what you really need now and what can wait. Launch is not the end, we look forward to a long term relationship helping you progress your web presence, there is plenty of time to make changes once we get the new site out there.
Tags: code freeze, code validation, debugging, launch, testing, web application, website