Branch Briefing – Don’t Bin It. Succeed With It.

Thanks to everyone who was able to attend our last Branch Event. It was great to see so many new and familiar faces and yes the cheesecakes were pretty special – thanks SakkuSamba for such a great job!

Another special thanks needs to go to Ben who gave a great presentation about his experiences working with Legacy software and his team’s approach to working with existing projects rather than starting from scratch, even if it doesn’t always work out, as Ben himself pointed out.

Ben highlights 3 approaches when working with a legacy pieces of software:

1) Green-field – start again with a clean slate, this gives you a great way to build from the ground up. This can be especially useful when making major changes to either UI or the feature set but has obvious downsides such as waiting for the new product.

2) Indefinite Triage – this is constantly working with and improving on your current product. It means you can get quicker releases and improvements but the problem is sometimes working this way can mean further down the line your software can become unwieldy and no longer fit for purpose.

3) A Hybrid Approach – seeking to get the best of both worlds, you can work to improve and release new features for a legacy project whilst working toward a longer term vision to relaunch a new product written to be more streamlined and easier to maintain in the long term.

Ben went on to discuss how he doesn’t have a template to make the decision on which approach to take, adopting a case by case approach to these projects. It is hopefully easy to see the benefits and weaknesses of each option when it comes to this decision.

Some Home Truths about legacy software

Key issues Ben has faced:

Updating legacy software is hard: it doesn’t always work.
It isn’t always cheaper than starting again.
The task upfront is always daunting.
Take baby steps and focus on small but critical wins.
There can be resistance from teams and this can cause bigger issues moving forward.

When it has gone well

Ben shared some case studies with some learnings made from 2 successful projects and one not so successful project and how that has changed his approaches and thoughts before embarking on new projects.

When projects have gone well the underlying software has always been fully supported. Working with outdated systems is a red flag, and is normally a good reason to take a greenfield approach.

Taking it one module at a time can really help clean up code effectively. As discussed, it can be a “monolithic task” to refactor a piece of software but taking it one bit at a time allows everyone to focus on a small and achievable task which will have significant long term impacts.

Standardising code bases is important. Over time software can branch all over the place and new tech, features and requirements are added to software systems that were not originally designed for all of this. This can create a wide variety of code and working on bringing that back to a standard codebase can create huge benefits to the project and the long term plans for the software.

When it all went wrong

Not all stories have a happy ending. Ben has learnt to look out for the following red flags from his less successful experiences.

Having no documentation can lead to major issues and bunch of learning/assumptions which can open up issues that no one involved was originally aware of. This seems obvious but sometimes if this isn’t available it can lead to wrong decisions being made upfront.

When coding best practices are clearly absent it can make it much more difficult to work with. Always take, at the very least, a proverbial peek under the hood of the software project, if not a full code audit. If it looks like a mess, it probably is, and it is therefore worth steering clear of.

Lastly, and Ben was extremely keen to stress this point, was resistance. If there is resistance for change from either stakeholders or internal developers of a project it can lead to a long term issues. Change needs to be embraced wholeheartedly and one of the challenges Benhas faced is overcoming that barrier with key stakeholders. In his experience, if it’s clear you can’t get buy-in then it will only make the task harder, if not impossible, to achieve. Secure buy-in from everyone involved, and don’t proceed without it.

Thanks again to Ben for his time and expertise and for everyone who came along and made the discussion.

Below are some key observations made by some members that I think are worth repeating:

20% of each sprint should be working on the legacy issues, as this can help keep projects being successful in the long term – Sym

Keep the conversation positive with resistant people. Sometimes they can become your strongest champions when they can see the positive impact for them – Rachel

UI often slows down core enterprise tech solutions and we need to strip backend systems down to keep the speed up. – Pete

Thanks again and we hope to see you at the next event – keep up to date on all our upcoming events here.