When thinking of Risk Management, the fields that typically come to mind include finance, investing and insurance. By definition, risk management refers to the strategic application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events.
If you run a web-based business, invest in PPC or SEO, or make your living entirely or even partially using your website, you should have a risk management strategy or at least understand what risks you might be facing. Risks like bad links, code errors appearing on a page, Javascript problems preventing site statistics from getting sent to Google Analytics or SiteCatalyst correctly… any number of problems with website code can have a damaging effect on your data, and ultimately, your bottom line.
It might seem like a typo or small glitch on your website is not really a big deal. Most websites have at least a few issues, right? While it’s true that very few websites are 100% error free, remember that you never have a second chance to make a first impression, and even small, subtle inconsistencies can have a tarnishing effect on your overall brand impact.
Of course, if your landing page or site crashes, you may never get the chance to get that visitor back again, because she may bounce and buy from your competitor instead of from you. Furthermore, invisible errors in side code can cause your site to be unnecessarily slow, and fill up your server log files prematurely. Worst of all – you might not be able to see the full picture of site coding errors in your analytics data, either, because code issues can prevent analytics from being captured accurately and completely.
Risks of making changes
Every change you make to your website is a potential for an unfortunate event, no matter how small. Even something as simple as publishing a blog article before it’s approved, having typographical errors, or even an incorrectly coded special character, could have a negative impact on your audience. Adding a new section of content without checking links can leave some visitors stranded and frustrated, producing bounced visits, and visitors that may never return. Untested code with one logical code flaw or bad SQL query can produce dramatic ill effects on your server, with outages, downtime or even causing data corruption in your database. What would you do if your site was down for several hours or even days, while you pay your IT team double overtime to restore data that became corrupted?
Embracing Change
Two forces are diametrically opposed when it comes to a living, thriving website for a modern online marketer. On one end of the spectrum is the idea that as digital marketers, we should always be testing. Michael Straker’s recent article gives plenty of excuses companies use to avoid testing new site features, but the truth is, we would all agree that the more you can be testing, the more likely you are to find the sweet spot in your marketing mix and increase profits.
On the other hand, IT departments know that with every change they are asked to implement, some level of risk is involved. Even for small content changes such as adding a page on your site or making changes to an active website always involves some level of risk, which is why risk management applied to IT is often called change management.
These two opposing goals might seem mutually exclusive, but with careful planning and and a disciplined process, they can happily coexist. Though risk assessment, risk management and change management are all slightly different, all areas of study can be applied to websites and online applications.
As web application architects who work for a company that specializes in measuring online marketing campaigns and improving website performance, we manage the risks of change in several different ways. As an agency, we help our clients develop strategies for implementing change in ways that greatly reduce, or even eliminate, the risks of making website changes. We want your marketing team and company owners to be able to try anything, but also to be sure that anything they try will be executed flawlessly. With careful planning, and not only expecting change, but welcoming it, change management is built into our process from the start.
Reducing risk with source code control
A number of SCMs, or Source Code Management systems, are available, including CVS, Visual Source Safe, Subversion, Mercurial and Git. You may have heard of Github.com, the social coding website that lets millions of programmers around the world share code snippets and projects with each other. Implementing an SCM is one of the cornerstones of change management for any modern web application.
One of the key benefits of having your source code in a repository is that it provides insurance of being able to step backward in time, to the point just before the code bug was introduced, and gives developers the ability to examine the code just before and immediately after a bug is identified. Is your website code stored in an SCM? Do you know how to view the commit logs? If you do nothing more to mitigate risk, please, at least store a revision history of the changes you make to your website code.
Reducing risk with workflow
The typical workflow for a web developer is to build something on her local machine, commit her changes to the repository, push it to dev, test it, and when a code milestone is reached, it’s copied to staging, where it can be previewed by the QA department and also the client. When a client approves a code milestone, that version of the code is sent to Production, or the live server environment.
This is in stark contrast to a single “production only” server environment in which your cowboy coder logs into the live server and hacks up some quick fixes in real time, hoping nobody is actively visiting the application page(s) being worked on. Even the most seasoned system administrators have a tough time executing work perfectly and instantly, and for a high-traffic website, every second matters.
Common coder humor is to say, “Well, it worked on my computer!” When that same code doesn’t work on Production, it’s no laughing matter. Having a process to test on a different computer is a must. What workflow do your programmers follow?
It’s impossible to cover the topic of web development workflows without mentioning SCRUM or agile methodologies. Modern web development teams typically follow an iterative approach to implementing changes. Typically a sprint, or code writing cycle, lasts two to four weeks, during which the programmers all work towards finishing stories, or feature use cases, that have been allocated for the current period of work. Agile software development is one of the many tools we use to write code, and is the subject of numerous books, websites and entire degree programs.
Reducing risk with multiple environments
Very few web designers have a risk assessment strategy, much less a change management plan. That’s where making the investment in a professional web development service provider can really shine. For example, as a matter of practice, at Cardinal Path, we create for our client projects at least two, often three or even four separate environments when working on a web application project.
Local => Development => Staging => Production
Typically these environments are called Development, or “Dev,” Staging or “Stage,” and Production or “Prod”. This is in addition to each developer having his or her own local environment. By being able to test hourly on the development server, daily on the staging server, and keeping the production server free from partially-implemented code, we ensure that when the time does come to deploy approved changes that they’ve been thoroughly tested.
Reducing risk with collaboration
A development server is typically used in-house, on the LAN, behind the firewall, or on a Virtual Private Network (VPC) attached to the company’s intranet. A source code repository provides all the developers on the team with a way to import each other’s changes and test on local machines. Development servers provide multiple developers in the organization and the project manager with a common place to run the web application as it is being built, so everyone can see the progress. The dev server also is commonly used by the quality assurance team to provide a real-time feedback loop back to the dev team of what’s working and if anything broke at the last commit. Regular code reviews with peers and managers provide a safe way to try new coding practices and provide shared responsibility across the engineering team.
Reducing risk with automated testing
It’s quite common to configure a build script as a post-commit hook on the company’s source code management (SCM) system, so that each time new code is committed by any of the developers, a new version of the application is copied to the development server for testing internally. When new code is pushed to the development server, we can automatically run unit tests on the server side code, and functional tests on the browser code. Technologies such as PHPUnit and Selenium let developers write code that tests the code they’ve written. This automated feedback loop can, in turn, let the developer who committed a bug see that his work has produced an error, and often, point to the exact file, function and line of code where the syntax needs to be fixed.
All of these various code development methodologies were created for building better software, in fields like engineering, aerospace and healthcare, but they apply just as well to modern web applications. Each server environment creates a bubble of protection, insulating your production web server from the risks of untested changes, a bad code patch, or unforeseen errors, and ultimately, keeps your production website running smooth and free from bugs and defects—issues that can prevent a sale, frustrate your visitors and tarnish your brand image.
