Nicholas Langley

Fixing Horror Software Projects

This blog is for all those companies out there who are stuck in a rut with their current developers.

  • Feel like you're going nowhere fast?
  • Stuck in a bug fixing cycle?
  • Growing list of updates?

Today is your lucky day, we love taking on and fixing terrible projects. Maybe it's the challenge that gets us going or maybe just our passion for getting you back up and running.

Here's five things we consider when taking on your nightmare project.

1 - Code Repository

This is the place where the code is stored, we want to find out whether there has been any version control or backup plans, this is the first indicator that the project is organised. (Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later on)

2 - Code Structure

We as developers look at the project and see how it is physically structured. This can only be done once we have our hands on the code.

Good projects tend to have 'design patterns'. Just as architects designing houses and buildings can develop templates for where things like bathrooms should be located, or how a kitchen should be configured. Having those templates, or design patterns, means they can design better buildings more quickly. The same applies to software.

3 - Integrity

What does the standard of code look like, we scour through the project to work out the quality of the code. We are looking for a common visual style, strict naming conventions and syntax rules that together produce consistent code which is easy to read and maintain. Readable, maintainable code is easier to work with and develop on top of, whereas 'spaghetti' code will take longer to tackle.

Spaghetti code is a pejorative phrase for source code that has a complex and tangled control structure, especially one using many GOTO statements, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled.

4 - Security

We are looking to see whether the project has any secure coding practises, we do that by looking at the following;

Validating inputs, security policies, access decisions based on permission rather than exclusion and hashing sensitive data.

If we do not find any of these the project is under immediate risk and a plan should be formulated to bring the project up to a secure standard.

5 - Communication

Communication with the original developer is important to give us a better understanding of the project if no documentation is provided.

We'll need access to the live systems and we may need some explanation of coding structures and any third party tools and integrations that are being used.

Conclusion

If you are struggling with your current developers come and talk to us for a free audit. No matter what the answers to these questions, we would always be able to advise on the best commercial action going forward.

Thought we would end on a nice quote from a client we have worked with recently:

Thanks again for all of your help to date on all of our projects, especially those of a more challenging nature! I very much look forward to us all working together on many projects in the future, just wish I had discovered you guys a couple of years ago.