What do you do if you're a software engineer facing conflicts with technical debt or legacy code?

Legacy code is not always bad; Technical Debt is not always evil. Sometime it’s prudent to take the approach of don’t fix what’s not broken, but only if you find yourself in that situation. More than likely, people find themselves on the other side of this spectrum though. I agree with everything that has been contributed so far especially the human aspect and change management side of things. Too often, IT comes out of the gate with a noble intention to write down the technical debt, but it soon becomes a charade if the value proposition and impact on users for this is not discussed in the open.

Availability of people with the specific skills is a factor to also consider. For example, at one time, the only reason migration of code was done since COBOL programmers were not available or exorbitant. Also consider low hanging fruits such as APIs available and easily integrate-able while replacing large parts of a legacy code. Weak areas (susceptible to bugs, legacy or otherwise) is another aspect to consider.

While evaluating the impact of technical debt, don't forget to consider the human factor. How is it affecting your team's morale and productivity? Is it causing frustration or burnout? Remember, your team is your most valuable asset. If the technical debt is negatively impacting your team's efficiency or happiness, it might be worth prioritizing its resolution. Also, consider the learning opportunities that tackling technical debt can provide for your team. It's a chance to improve coding practices, learn new technologies, and foster a culture of continuous improvement.

If there is any technical issues wrt legacy code, Below are the checks to be performed to access the impact of the code and update solutions. 1. Check the documentations of legacy code. Look for any logical justifications wrt to any findings found earlier. 2. Analyse and understand impact of the code in the perspective of functionality, run time failures, and code metrics. 3. If there is any impact in the code, developers to come up with better solutions. 4. Have the discussion with all reviewers to access the impact of the code and solutions provided by developers and collaboratively devise solutions to address it.

Technical debt is something that you have to review frequently/periodically to stay on top of the situation. I would like to ask these questions from my team/myself to assess the situation. ?Are you struggling to understand an old code? ?Do you think the function/code block is unnecessarily long? ?Is a certain code/function giving you errors constantly and, due to its complexity, hard to follow? ?Has the particular code/function been done in preparation for a demo of some sort? Is there any comment /documentation to warrant that? ?Is the code/function of interest dependent on an obsolete /vulnerable package? If you say yes to any of those questions, you will need to prioritise resolving those debts. I hope this helps. Thank you.

Remember, Rome wasn't built in a day. The same applies to tackling technical debt. It's a marathon, not a sprint. Start by identifying quick wins, those low-effort, high-impact tasks that can immediately demonstrate value and build momentum. Celebrate these wins to boost team morale. Then, gradually tackle the more complex issues. It's also important to communicate your progress and the value of this work to stakeholders. This can help secure their buy-in and support for ongoing efforts. Lastly, don't forget to incorporate lessons learned into your future work to prevent the accumulation of new technical debt.

Strategically tackle technical debt by breaking down tasks, prioritizing based on impact and complexity, and setting both short-term and long-term goals. Start with quick wins to boost morale, then address more complex issues. Use dedicated sprints, a debt ceiling policy, and create tickets for tech debt to make it manageable. Incorporate pair programming, maintain code quality metrics, and ensure thorough documentation. Educate your team through workshops and create a community focused on code quality. Balance new features with debt reduction. Remember, reducing technical debt is a continuous process that requires regular reassessment and adaptation.

Visualize the parts that are most valuable to your business and create a formula to rank the most important improvements, starting with the most cost-effective tasks. Use a tool to measure code quality and security to measure your progress.

Refactoring can be seen as a form of preventive maintenance for your codebase. It's not just about cleaning up the code, but also about understanding it better. As you refactor, you'll likely discover patterns and design principles that can guide future development. This can lead to more efficient and effective coding practices. Remember, the goal is not to make the code perfect, but better. It's a continuous process, much like brushing your teeth. You don't wait until you have a cavity to start brushing, you do it regularly to prevent problems. Similarly, don't wait for your code to become a tangled mess before you start refactoring. Make it a regular part of your development process.

Refactoring techniques include the Progressive Enhancement Approach, Component-wise Refactoring, Test-Driven Development, Peer Programming Sessions, and dedicated Refactoring Fridays. Emphasize code review with a refactoring perspective, gamify the process, adopt a Scout Rule for continual improvement, utilize Feature Flags for safer deployment, and employ Legacy Wrapper Techniques to bridge old and new code seamlessly.

When there's not enough bandwidth available with the team, refactoring the code base gradually is the approach that can come handy. Analyse and identify which layer of your code base when refactored can provide high rewards for the components. Like better throughput, better response times or higher cost benefits. Some of the tech debt items that can be gradually refactored, making DB/Cache layer non blocking ( reactor framework ), circuit breakers for making 3rd party API calls, proper connection pooling etc

Once technical debt reaches a certain level, the enterprise can become paralyzed in fear of any significant changes to the code base. Putting emphasis on low risk strategies like refactoring and strangulation is important to build support for the work.

Having testing methodologies in place certainly helps sort out technical debts as well as prevent future technical debts from happening. ?Unit testing ?Black box testing ?End-2-end testing ?Functional testing Are some of the testing approaches that you can introduce to fault proof your application. I hope this helps. Thank you

Having automated tests in place can give you a lot of comfort, until you realise that the test set is incomplete and production has just found the gap. Test the tests.

In summary, ?When sorting out technical debt, it is really important that higher management are in agreement. ?In the end, it is a constant juggle between introducing new features, fixing bugs, and resolving technical debts. ?Since a sorted technical debt is not so apparent, like adding a new shiny feature, it is important that all stakeholders are aware of the situation and understand the importance of spending time sorting technical debt. ?Highlight how important it is to have a maintainable code base. I hope this helps, thanks

In the initial phases of development, it's okay to accumulate some technical debt as the main focus is on implementing features. However, it is essential to prioritize how to avoid such debt in future releases and to work on improving the existing code base by adhering to standard practices. Teams can hold sessions and programs to discuss plans for implementing these practices in phases, with senior developers sharing their experiences with junior team members. Additionally, incorporating pair programming sessions can greatly enhance code quality and knowledge sharing within the team.

To address technical debt and legacy code issues, it is crucial to embrace best practices that promote code quality and sustainability. This includes writing clean, well-documented code, adhering to design patterns, and following coding standards. Encouraging code reviews and pair programming can also facilitate knowledge sharing within the team, leading to a more robust codebase.

Software engineers facing technical debt or legacy code conflicts can take proactive measures to address these challenges. They should assess the impact of the issues, strategically plan for resolution, gradually refactor code, automate testing processes, communicate clearly with team members, and embrace best practices such as writing clean code and conducting code reviews. Additionally, considering factors like team collaboration, knowledge sharing, and continuous improvement can help in effectively managing conflicts and maintaining a healthy codebase.

While work generally needs to be tied to business value, It's important to build in time for debt reduction activities to avoid the perception of loss of progress.