Associations
Nonprofits
Web development

6 web development pitfalls to avoid

In make-believe land, technology projects come in under budget, ahead of schedule, and without any unforeseen issues. Let’s be honest here…in the real world, tech projects can be challenging. We’re dealing with all the wants and needs for the new tool, technical (and maybe emotional!) baggage from past projects, sometimes multiple systems that all need to lay well together, and humans with thoughts and opinions and responsibilities. Phew, that’s a lot.

The good news is that, when you’re working with a trusted partner like Fíonta, you can rest easy knowing that we have managed technology projects of all shapes and sizes for almost 20 years at this point. We’ve learned what works well, what kinds of conversations need to occur and when, and how to anticipate risk with prudent planning and respond to it with pragmatism.  

With that, let’s have a look at some of the most common issues along with suggestions for avoiding, or responding to, them.

1. Allowing your website to become outdated

While this sounds like an obvious no-no, this is probably the most common issue for existing sites. The vast majority of websites built these days use a Content Management System (CMS) like Drupal or WordPress, and these CMSs and their associated plugins feature regular updates. They can include fixes of security issues or bugs and delivery of new features. Even if your site is intended to be fairly static, these updates are incredibly important. Failure to perform security updates in a timely fashion can result in your website being hacked which, at the “best” may result in a poor user experience or display to the worst, a website that doesn’t load or may even be inaccessible to administrators.

When the core CMS is updated, all dependent plugins also need to be updated in order to stay compatible. A plugin security release may only be possible to apply if the core CMS is also fully up to date. The best way to resolve this is to perform regular maintenance, monthly or at least quarterly, depending on the complexity of the site, and include off-cycle updates when critical security fixes are released.

2. Not using source control

Source control is essentially a revision history for code. With source control enabled, developers can see exactly what changed, when, and by whom. If needed, we can roll back a change—it’s like time travel superhero stuff! If a bug fix or feature is deployed live and somehow breaks the live site, we can quickly recover by using the source control to revert to a previous version. Without source control, every single change would have to be manually changed back, which is easier said than done. If there are multiple developers and one pushes broken code live and then leaves for the day, how is the next developer to know what changed? Source control is transparent to clients/site owners, so if you’re not sure if your site is on source control, ask your developer or us. If it’s not, the easy fix is to add it.

3. Developing on the live site

We always recommend having a “dev” or “QA” site to test changes on before pushing them to the live site. Some organizations balk at this as it may incur an additional web hosting cost and will require maintenance like any website. If ever there was an apt use of penny wise and pound foolish, however, this would be it. Developing on a live site is just plain risky. If you’re not sure if you have a dev site, ask your developer!

Side note: Sites hosted on Pantheon automatically come with source control and dev/test environments. As more organizations switch to these kinds of managed hosting, this becomes less common of an issue. Organizations who manage their own hosting through a platform like Amazon Web Services do need to verify they are set up with source control and a dev site.

4. Not agreeing on common vocabulary

As mentioned above, technology projects are undertaken by…people. And people are (thank goodness for this!) different from each other. By and large, successful projects include a broad range of inputs and require a mix of personalities, not all of whom will speak the same technical language.

A strategic project manager will ensure that each project and all team members utilize a shared vocabulary. For example, what do you think of when you hear the word, “page”? Someone wearing an analytics hat may assume a page is a URL, one webpage. A WordPress developer thinks of the specific content type called a Page (different than a Post), while a Drupal developer thinks of content labeled “page”. Even the capitalization (or not) of the first letter can have a meaning.

There’s also an art to gathering requirements and making sure that all functional needs are cataloged and broadly understood before design or development begins. A team member on the client side could feel like the need has been articulated in meetings and received and yet feel surprised when the feature is ready for testing and it does not reflect the initial request.

5. Failing to user test

Don’t forget, not only are people involved with creating and developing the website or new tool but that, at the end of the day, it’s other people who will be using it. Good UX (user experience) can’t be created in a vacuum and certainly shouldn’t be an afterthought. Engage with the UX specialist on your team early and often and user test as much as you’re able. An investment in end-user testing will pay dividends.

6. Not adhering to sprint schedule or frequent pushes to live

We’ve talked about using dev or QA sites for testing prior to pushing, using source control to keep track of what has changed and when, and the necessity of timely maintenance. So, onto the last risk for this blog post.

Here’s the scenario – a new feature is under development and on the QA site for review and testing, but other priorities take over for the client. This happens, we get that. The problem is that the longer the new feature stays undeployed to live, the more out of sync QA and Live become. This means that we can’t push maintenance updates live in a timely manner and, as you’ve probably gleaned by now, that is a liability. As best as possible, sticking to the schedule – or communicating with the project manager at the first sign of delay – is the prudent course of action.

The wonderful news is that technology projects are exciting, impactful, and can truly be transformational for nonprofits and associations. With an understanding of the risks, clear communication, and across the board engagement, every project can be a success.

Reach out to Fíonta if you want to learn more about our web development process or discuss a support or maintenance package.