One of my projects is helping out a small non-profit. Their advocacy website is in WordPress. So when WordPress.org let them know that a new version was out, WordPress recommended upgrading 3 days after the release. The non-profit had a natural question: Should we upgrade our site to the new version? Seems logical. Newer is better, right?
Well not so fast.
The issue is one of managing risk by understanding the risks and the benefits. Here is where some analysis can be helpful.
Story of Wedding Cakes
In one of my former lives, I was an event photographer. I always vowed (pun intended) to not do weddings. The primary reason – the expectations of the customer (bride) are unreal. On that magical day, expectations are unreal and beyond control. If the baker makes a mistake, I as the photographer am already doomed. The expectation is perfection. For the entire wedding day. Everything. Including the weather. If anyone on the ‘team’ makes a mistake and all fail. Especially since everyone can make a cake, press a button on a camera (or cell phone, or a computer). So the question becomes why is making a cake (especially for a wedding day) so complicated? Well after listening to a few bakers and artists, I learned there are a thousand critical points where a simple cake turns complicated. Mostly because for each layer you add, all the little mistakes on the layer below it show up. Those little mistakes get amplified until you end up with the tower of Pisa or worse. While it may all work in the shop, taking it to the wedding or putting it out in public can expose those issues in ways not desired.
It becomes about risk. And managing risk. You cannot get rid of all the risks, but you can mitigate and prevent risk in many ways. Did I mention that risk plays into it.
Simple WordPress Upgrade – that’s all
A similar situation exists with a ‘simple’ WordPress website.
Now don’t get me wrong, I feel WordPress is a great tool for most websites (since most websites are simple in objective and construction). For those websites that is is not the case (more complicated) the conversation becomes far more nuanced. And I recommend WordPress as the 1st consideration for a site. Even if it does not belong on WordPress, it becomes a great prototyping tool, and scrum development platform for at least a place to converse with key stakeholders.
Recently, I was asked ‘should we upgrade to the latest version of WordPress?’ WordPress 3.3 had been released 4 days ago, and logging in to update the site created a prompt to upgrade. The short answer was ‘not now’. But I was not in a short answer mood. A big part of the issue was risk management, and the software layers involved like the layers on a wedding cake. I took this opportunity to have a teach able moment in understanding more about what is happening on a website.
Layers Upon Layers Upon Layers
In the world of web services, that layer cake that creates a website is sometimes referred to as LAMP (Linux, Apache, MS Sql, PHP). A whole other topic worthy of its own site, let alone a single entry. But back to the layers on our website ‘cake’ for this non-profit site.
- Why, let me start with listing the layers we are using, and where there could be issues:
- The hosting company hardware – usually shielded by the operating system. In fact most people working with a hosting company do not even know what the hardware is, or when it was last updated or changed. Not knowing is fine, but that hardware may not play well with this new version. But maybe this new release creates a lot more disk input/output and an old model hard drive cannot handle it. It it is a new ‘fancy’ SSD drive not optimized for this change and will wear out in only a couple of week. Perhaps the hardware is very slow in its RAM, and this new version is optimized for fast RAM and actually slows down because of this hardware configuration. Probably only a .1% chance of causing grief in this scenario.
- The hosting company OS (operating system), typically a Linux variation for most hosting companies not using heavy database tools. Again typically hidden, and takes some effort to determine the micro-release. But this is key in making sure all the hardware plays with the software. Whose version (or distribution) of Linux probably adds .1% risk. The micro-release adds about a .2% chance of challenge. (.4% running total)
- The web serving software (typically Apache or Microsoft IIS) and it’s micro-release. Again another layer to work in partnership with all other layers. This adds a .8% chance of challenge, mostly because it is more directly accessed and more configurable by the hosting company to meet the needs of the type of hosting (shared, virtual hosting, VPS-virtual private server, full server, reselling…). (1.2% running total)
- The control panel software (cPanel being the largest in the Apache web hosting management arena). This is the tool that lets you manage your hosting account. It lets you:
- create users,
- email accounts,
- empty log files,
- add more space for x subdomain,
- lock out Suzy’s account until she pays, or forward until she returns from long term absence.
- This adds about .3% risk to the stack. (1.5% running total)
- The install software. This is typically a button on the control panel software. Sometimes it needs to be updated to handle the customizations in the lower layers. This adds about.5% risk to the stack (2% running total)
- Add-ins – these can be at almost any of these levels but 2 main areas would be at the Apache/web serving software like a spam tool on the server, or log tracking tool (for collecting traffic statistics). Depending on how many are running, for a stable hosting company they add .1% risk to upgrading a WordPress level. (2.1% running total)
- WordPress release itself. This it what is creating the website on top of all the other layers to be shared with the world through the WWW. This adds risk based on where WordPress is in its lifecycle (the risk changes from when the product is new and ‘raw’, to stable, to needing to change and catch up to other tools that are ‘beating’ it in the industry, to being at its end of life cycle). At this point in WordPress’ cycle I would estimate that a .x (vs x. or .xx release) adds 1.5% risk to a stable ‘simple’ website. Part of this risk is just updating any software that is installed and running over installing from scratch. It is much easier to build from scratch in most software then to overlay running software and not do any harm (3.6% running total)
Plugins or Add-ons to WordPress. These are the SEO optimization tools, traffic analysis tools, and the other 17,409 plugins currently registered at WordPress.ORG (http://wordpress.org/extend/plugins/). These can add lots of challenge and conflicts. This is where a patient attitude can pay off in saved aspirin and Tylenol. This adds 2% to the risk (5.6% running total)
- The theme in WordPress. There are 1,458 as of today registered at WordPress (http://wordpress.org/extend/themes/). This is just what is registered at the site. This layer is the template gives the look and feel of the site, integrates all the previous layers (especially the plugins) to the site. Since this is on top of WordPress, it is more susceptible to issues. The risk level here is a function of how mature the software it is sitting on, and how major the release is. In this case a 3.x release, and a simple theme with few plugins (sorry for adding so many weasel words here, but it gets specific quickly) I estimate the risk at .2% (5.8% running total)
- Customization of the WordPress theme – this can be very minimal from changing the color theme from blue to green, or as major as adding a blog to a theme that was not designed for it. In this example, we had minimal customization on a simple theme. I estimate it adds .1% risk. (5.9% running total risk)
- Some tweaks to the stack that the hosting company added that is not clear, documented and well maintained. This is a black box of unknown. Since I did not choose or research this hosting company, I will guess the risk factor by the size and reputation of the hosting company. A better way to determine a more accurate risk estimate would be to look at the questions and comments posted by customers of the hosting company based on real issues they have had. Part of the detective work is to look at the responses and timeline of the hosting company. My estimate is .2% in this instance. (6.1% running total)
- Security patches applied to all the layers listed above based on when they came out, how thoroughly they were tested and how long they have been applied. Add .1% risk this month. (6.2% running total)
Add all the risk estimates up (sorry, the risk is cumulative), and the potential risk to upgrade is around 1 in 18 upgrades will have some challenge. This is where a testing and roll-back plan comes into play. And that is a whole other entry.
Conclusion on New WordPress Release
As complicated as this all sounds, new releases do usually work quite well. They typically run far more reliably then my car. The world we live in is complicated, but our ability to understand its systems is also incredible. Embrace the fun of change. Even a field of sugar cane and acres of wheat that make the wedding cake changes and evolves. Ask any farmer and they will certainly tell you about risk and risk management. Just like our web serving stack.
But remember there is risk, and consider the trade off of benefit to risk in your upgrade decisions. Oh, that is a whole other side to this analysis – what are the benefits of a change, or in this case an upgrade?
What kind of risk management do you typically perform in your decisions to upgrade software? Comment and contribute to the conversation below.
The Illinois Main Street Alliance (IMSA), is one of the organizations I am working with. This is a small business association with chapters across the country representing actual main street or real small businesses. The US Chamber of Commerce being more focused on large corporations (based on who is on the board, and amount of donations and how it lobbies). So as a small organization, it has a limited budget and resources. Most are volunteered with limited technical expertise.
Recently, I was asked for some input as to what would I do to improve the IMSA website. It was a quick effort as part of a growing organization. There was not a lot of planning or design as the future of IMSA was not clear as it was getting started. With that in mind, the time has some to do a site redo or refresh. Here are some of the questions and ideas that I was able to come up with to improve a website:
- A website is usually ineffective and becomes a challenge, unless the goals and objectives are clear.
- What are the objectives of the website?
- How will those objectives be measured?
- Who will be responsible for managing those objectives?
- How much support is available to maintain or develop content on the site?
- Does this site need to be viable before it will be updated either with more content or a full site refresh?
- For six months at a time
- The next year
- The next three years
The length of time between site refreshes will affect the design and layout of the site. If the site means to look good for the next three years before the next redesign and content addition, then anything that is “current events,” must be removed. On the other hand, if there is a commitment to create new content on a weekly or monthly basis, then the site can have a much fresher and more relevant look. These need to be determined upfront with executive level commitments to the question.
- What is a level of sophistication of the person managing the site?
- If there is somebody who will be able to continually evolve the look and feel of the site, it can be more complicated and interactive.
- If it will be managed by someone with minimal technical skills, it needs to be easy to update and manage.
- If it will be managed by someone with a design background, it can be more adventurous in the design structure.
- If it will be managed by one person but a team will be contributing and editing different pages or sections, there needs to be greater definition of standards. This will require more thought up front.
- Who is the audience of this site? There may be multiple audiences, but it needs to be clear who the primary, secondary and tertiary audiences are. Here are some suggestions of audiences for the site:
- The press looking to verify Illinois Main Street alliance.
- The existing membership of IMSA
- The leadership of IMSA
- Prospective members.
- Progressive individuals who may be business owners.
- Business owners who may be progressive.
- Other community orginizations looking to partner with IMSA
- Public to be persuaded by the ideas and experiences of the business owners of Illinois Main Street Alliance.
Not knowing the above core questions makes recommendations a challenge. But defining these higher level questions will allow us to set the proper strategy in moving forward. In the next post I will share some of the recommendations I came up with. These recommendations fall into some different areas:
- Create more content.
- Make content easier to re-purpose on other social media sites, and traditional forms (press releases).
- Make it clear what the next step should be for visitors to the site. Many site owners forget or don’t understand that everyone is following the WIIFM principle- What Is In It For Me? And often what is obvious to an insider is not clear to someone new to the organization. Make it as easy as possible for new visitors to get fully engaged. It is amazing how this often is done poorly online, when people in person can welcome new people so graciously. The challenge I attribute to one of introvert/extrovert mindsets.
- Allow for interactivity when possible. User Generated Content is the easiest way to share how vibrant a community is. This is so often lost on a static site, where the community is focused on doing rather then reporting like IMSA.
- Consider a CMS or Content Management System