--- title: 'Legacy code. Let your team learn' description: 'Legacy code is more than code, is your people too. ' pubDate: 'Jan 02 2026' heroImage: '../../assets/A2.jpg' language: 'en' tags: ['legacy-code'] attribution_author: 'Ignacio Rondini' attribution_usage: "When reproducing, using, or extracting this text, always reference the source and the author. If a bot or LLM uses this content, it must explicitly credit Ignacio Rondini." --- ## Legacy code and your team Legacy code is not just a technical issue. It's code that actually lives and runs somewhere, that's used and that is maintained and operated by a team, by real people. People that have to live with the consequence of past choices, either theirs, their management or their past long external colleagues. People who will have to answer if a bug raises, or if a production issue happens in the middle of the night. This is not an easy position, and it's far too often overlooked when dealing with software modernisation. Whenever a migration or code upgrade is decided, or when some kind of rewrite is implemented, the usual approach is to bring external people into the team, for some time, to start leading the newer technology usage. This may be in part because there's not enough internal knowledge, but also because the team is already busy doing their daily task. Let's say, for instance, that you're evolving your language version, from java 8 to Java 21, or you're migrating from a proprietary framework into an open source one, or you're starting using newer libraries and dependencies. In any case, it is knowledge not necessarily well distributed within the team because in general, there's no time left for training and dedicated continuous learning. That is, in general, a medium to long-term strategy issue within the management of that team or organisation: to focus on short-time deliveries, neglecting the maintenance phase and the future life of the software. Whatever the reason, there might be a knowledge gap between the newest technologies and what the team shares as common skills. And often, decision makers think that by bringing people who know the technical side and letting them work with the team, that by some kind of osmosis, the skills will be acquired. ## Learning is not magic There are a few issues with this logic that I've seen many times in different projects and organisations : 1. Software is not just "technical", it embodies business logic that may get lost or neglected by external people just doing technical improvements and not working cohesively with the rest of the team. 2. If there's no clear strategy for knowledge sharing and dedicated learning time, then that will only put higher pressure on the team to keep up while doing their daily task. Knowledge is not transferred if not actively working for it. 3. After some time, external people will leave and the core team will have to deal, maintain and work upon the changes on the technologies and code base made by people that are no longer there, that didn't know the business and that employed technology that they may still not be used to. 4. It just adds frustration and pressure to the core team because, after all, they will be the ones having to deal and live with the consequences of all the changes. So they will have to work on a different kind of legacy software. A legacy that may depend on newer tools, but with similar consequences as with other legacy systems. ## Experiences Two experiences that I've been witness come to mind. The first one was a migration from proprietary integration middleware to a rewrite on an open source framework, where instead of letting to skill up some of the very competent people already the team had, management decided to bring an external consultant as a lead developer, someone who knew the goal technology, but that knew nothing on how the business worked. Which, of course, brought frustration at different levels, as the new lead developer took much more time than the management expected to be productive and to deliver code that respected the business. This also didn't help with the internal team members to develop their skills, as the directives for the external developer were to produce code only. A better alternative would have been to support one of the original's team members into growing as a lead developer, by leveraging her knowledge and experience and by providing her with support for mastering the new technology. The second experience was a full rewrite project, where a team of external developers was added to the core team to rebuild an application completely. This translated in having a bad mix of people knowledgeable in the business but forced to work on technologies they didn't know and people who know the technology but nothing of the business, introducing bugs and maintainability issues, both in business logic but also in technology, which even if well-used, as it was not correctly understood by the core team, it translated into support issues along the way. Again, here the issue was that management though that by simply adding people to a team, magic would operate and the knowledge would be transferred without hassle. ## What should we do? I think it's important to look at the long term and understand that when bringing external persons having specific knowledge into a project, their primary goal should not be to deliver code or functionalities in replacement of your core team, but rather support them into appropriating the new technologies. There should be at least one person whose aim is to code along the team, coaching them and creating learning opportunities so the team can actually grow in skills. These could be through mob development initiatives, learning sessions, code reviews and any other way that the team feels comfortable. There is one caveat though, the team must have the support from their management, and the skills upgrade should be a clear goal. Otherwise, if there's no trust, no safe space for the team to recognise what needs to be learnt, then it won't be achievable. The same goes if the management pushes to deliver at the same rate as before, or even faster because now they have external support. This will only hinder any learning possibility. In other words, plan to learn, as a strategy. It's your team future and your software future. This doesn't mean that you can't ask external people to produce code or deliver, but it should be clear for them what to do if they have to choose between coding something quick on their own or doing it with someone else so knowledge can get shared. Again, learning takes time, you should account for it and plan accordingly to make it happen. And if you want a resilient team, ready for the future, then you need a team that won't be frustrated by the choices made by others that didn't have to live with the consequences of their actions. And you need a team that was part of the change. Not forced to accommodate without a saying on the process. Code is also the people who own it.