Legacy Issues in External SW Development

90% or more of companies we talk to arrive on our doorstep with the solid conviction that they are the owners of a unique and unfathomable software legacy. Architecture is described as ‘interesting’, or ‘original’ or ‘highly creative’, the code base is not comprehensively documented.

Of these 90%, we would say 90% are overestimating common practice or underestimating themselves. In fact, on-boarding developers into a complex legacy is not more or less difficult if those developers are working remotely. It is, though, different and it’s worth taking an objective look at those differences.

The mechanics of getting the job done centre around communication. Without a net minimum of time (overhead) it will not be possible to let the new devs run free. In an in-house scenario, there is less need for discipline. Whilst this may be a comfortable arrangement for all concerned, it doesn’t lead to efficiency or enact the necessary steps for the creation of a future-proof code base. All participants are within earshot of each other: when an issue arises, it can be addressed (assuming, of course, all participants happen to be free…..).

SO:

If you’re going remote, start with a small team, maybe just two. Feed your new members small and repetitive tasks that you know how to do: they’re easy to explain if you’re doing them all the time.

Introduce pair programming and shared screens so you have 2 of everything and one resulting code. This allows a distributed team to work in step and in tandem.

One of the best practices is joint inspections: someone with experience reviews a less experienced team member. It can be very insightful upon the lapse of a couple of months to switch roles.

All new team members should also take part in reviewing. This will help give valuable background to them, and the whole team will get an interesting and maybe fresh view of what’s happening. Each solution review forces analytic thinking, which helps the overall quality of the code base.

During any tests, definitely involve new developers into the test. This is not often practised. When new developers have to do new tests, they get an understanding of the end user point of view much more quickly and this can only help to produce better solutions.

Be agile: it helps to be organised and share knowledge.

Jump in and get your hands dirty. If legacy issues are a barrier to growing your team and therefore business, address this issue and remove it.

Take a sober look at your budget. Whether we like it or not, improving the bottom line is why we come to work and defines how successful we are. If you are going to kick off an external team, this would (should) mean you’re going to have very significant cost savings. Identify a realistic number, forecast over 6 to 12 months and weigh that up against perceived inconvenience. Sometimes a bug is actually a feature….

Talk to those who’ve done it many, many times. This means developers, not just their managers or sales agents.

Two things are worth remembering here:

1. It is the absence of processes that leads to legacy issues.
2. Time is the single most valuable resource any enterprise has. The net time necessary to accomplish a satisfactory knowledge transfer doesn’t have to change because part of the team is in another building/city/country. By setting down ground rules, you will make more efficient use of your time.

If you want to find out more, just let us know. We are active and experienced members of the IT community who welcome the opportunity to communicate. We have seen this supposedly impossible task conquered many, many times and we’ll be happy to share our experience and give you practical insight.