Avoiding Inherited Project Horrors

You might inherit a project containing some creepy code from another developer or another agency, or from someone who has built their own website and now needs the help of an experienced developer. There are several risks associated with taking on a project that you have not been across from the very beginning. I am going to discuss some risks to consider when taking on an inherited project and how best to deal with them.

At Cogworks we’ve built 100’s of Umbraco sites, including setups with multiple brand sites where one site might have tens of thousands of nodes or big 3rd party integrations, and we’ve inherited our fair share of spooky codebases. Clients come to us as a trusted and active name in the community to fix their site, or even just for a health check (safe in the knowledge that they’re not going to get ghosted).

Common complaints we hear from clients coming to us to take over their projects:

1. “My site is slow and keeps crashing” - this is probably the most common reason why clients come to us
2. “My website is ineffective” - maybe the site is not ranking on search engines or not engaging users
3. “Our current agency sucks” - we often have people coming to us because they’ve lost trust in their old agency

We’ve developed our own process and checklist of things to look for in these situations based on our experience of finding too many skeletons hiding in the closets of projects we’ve inherited.

First and foremost: Code

Before agreeing to a new project, the first thing that we’ll look at is the code. It is very unlikely that we’ll agree to support a website without first seeing the code. 

It’s important to assess if the project is worth taking on, you don’t need to take on a project that’s so poorly done that it’s going to haunt you for the rest of your life.

We spend around a week sitting down and going through the codebase thoroughly, making sure we can run the site and identify any performance bottlenecks using tools such as ANTS and Loader.io to gain a real insight into where the code’s inefficiencies lie.

After our analysis, we produce a report for the client which has clear descriptions of the things that need fixing, and an estimate of the time needed before we agree to work on the project. We set priorities in high, medium, and low priority order so that we can effectively communicate to the client what’s wrong with the website. This is a particularly important step in the process to help effectively communicate the impact of a site’s issues - the client may not be overly technical, or honestly care too much, so they need it spelt out in plain English for them. This report will also form the basis of our task backlog on the project for the near future.

Being honest and transparent with a client is very important.

“If you can’t fix this soon… We’ll have to call an Umbraco expert!”

Those words are scary to hear from your new client who you thought you were treating well. But when communication breaks down, so does trust between you and your client. If you pretend to the client that everything is OK, but then work slower because of the pain that the project brings, you may end up losing the client. Being transparent about the project in hand and its issues builds a good relationship and they will be more lenient about paying more for your time to refactor code or fix things properly.

Pete Duncanson (@peteduncanson) gave a fantastic talk at uWestFest about not just being a developer, but also being a person. I recall the words “software with a smile” were used. I think this couldn’t be more true - it’s easy for developers to hide behind their screens but it’s equally as important they engage with the client.

All of our clients are assigned a project team, made up of a producer, a dedicated tech lead and an account manager. The technical lead may not necessarily be doing the code but they are there to own technical delivery of the project, for ensuring that we are delivering high-quality work and making sure that the client is happy. The team meets regularly and discusses upcoming work - we even host semi-regular socials with clients so the team can get to know them on a more personal level.

The proof is in the pudding

Days Out Guide is one of the sites that I worked on which was experiencing a lot of performance issues when they came to us for help. It’s a highly transactional site without a lot of static pages. There was a lot going on on the site. The client came to us with several critical issues:

• The site crashed at peak times.
• Their agency at the time couldn’t deliver on the requirements.
• They had wanted new features on the site for a very long time but they couldn’t trust the agency to implement them.

It’s almost the exact same story as with every client that comes to us: they have a problem, their agency couldn’t fix it, so then they come to us.

When we took the site on in May 2016, Days Out Guide was running on Umbraco 7.2.8, it took 1.5 seconds to load the homepage and under our load test could only handle 150 users per minute. Since we’ve worked on it, it’s now on the latest version of Umbraco, can handle 10,000 users (a 7000% improvement on before) and we’ve quartered the amount of server resources needed to run the site. We did this through our iterative process of going through the performance issues, finding the bottlenecks and resolving them incrementally.

Delivering high quality is just a matter of process

In short, our experience has shown that having a solid process in place and ensuring there is dedicated project leader around to “own” the delivery of a project results in vastly improved client relations but also reduces technical issues. As a developer, no one ever wants to be the one responsible for creating “legacy” code that people struggle to maintain in the future.

Follow this advice, and for your clients, it’ll be all treats and no tricks!