Refactoring Code Prior to Implementing New Features

𝗛𝗼𝘄 𝘁𝗼 𝗿𝗲𝗳𝗮𝗰𝘁𝗼𝗿 𝗹𝗲𝗴𝗮𝗰𝘆 𝗰𝗼𝗱𝗲 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗦𝘁𝗿𝗮𝗻𝗴𝗹𝗲𝗿 𝗙𝗶𝗴 𝗽𝗮𝘁𝘁𝗲𝗿𝗻 The Strangler Fig pattern allows you to grow new implementations around risky legacy code. Martin Fowler coined the metaphor after seeing vines that wrap around a host tree and eventually replace it. Instead of a risky “big-bang” rewrite, you wrap the old code with a thin layer, route new traffic to modern implementations, and retire the legacy code when coverage reaches 100%. Here are the steps to strange legacy code: 𝟭. 𝗘𝘅𝗽𝗼𝘀𝗲 𝗮 𝘀𝗹𝗶𝗺 𝗶𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲.Define the future API in a new class or adapter. No state moves yet; you’re just sketching the contract. 𝟮. 𝗥𝗲𝗱𝗶𝗿𝗲𝗰𝘁 𝗰𝗮𝗹𝗹𝗲𝗿𝘀. Point controllers, services, or endpoints at the new interface. The old class fades into the background. 𝟯. 𝗦𝗽𝗶𝗻 𝘂𝗽 𝗮 𝗻𝗲𝘄 𝗱𝗮𝘁𝗮 𝘀𝗼𝘂𝗿𝗰𝗲. Add the table, topic, or microservice that will own the extracted state. AWS and Azure both frame this as creating a “target” boundary. 𝟰. 𝗗𝗼𝘂𝗯𝗹𝗲-𝘄𝗿𝗶𝘁𝗲 (𝘀𝗵𝗮𝗱𝗼𝘄 𝘄𝗿𝗶𝘁𝗲𝘀). Within a single transaction, write to both the legacy and new stores. This keeps rollback trivial and lets you diff live traffic. 𝟱. 𝗕𝗮𝗰𝗸𝗳𝗶𝗹𝗹 𝗵𝗶𝘀𝘁𝗼𝗿𝘆. Batch-copy existing rows. Lock records or use idempotent upserts to stay consistent during the move. 𝟲. 𝗙𝗹𝗶𝗽 𝘁𝗵𝗲 𝗿𝗲𝗮𝗱𝘀. Switch getters to the new store. Monitor error budgets and latency; feature flag if you need a fast escape hatch. 𝟳. 𝗥𝗲𝗺𝗼𝘃𝗲 𝗹𝗲𝗴𝗮𝗰𝘆 𝗽𝗮𝗿𝘁𝘀. Delete legacy columns, routes, and test fixtures. Celebrate with green builds and simpler onboarding docs. Big-bang rewrites look heroic but often end as zombie projects. The Strangler Fig pattern enables you to refactor safely, deliver value continuously, and maintain a cleaner codebase every sprint. 

Over 140 tests deleted. One day well spent. If you're using AI to generate tests, you need to read this… 👇 Here's how I spent my day improving our codebase by removing code instead of adding it. It's not an old or complicated codebase. It's a backend for frontend—just wrapping API calls. This test redundancy problem isn't new, but AI coding agents make it worse. My initial strategy was to comment out test files and check the test coverage report. Most of the time, there was already sufficient coverage so the tests were redundant. The surprising thing was that a lot of the production code was only ever called from tests. This is hidden dead code and speculative generality. You're not gonna need it...and if you do, add it when you actually need it. This is part of the TDD mindset. Why did this cleanup take a whole day? Because tests are the specification of your codebase. When they're clear, readable, and focused on behavior rather than implementation details, refactoring becomes effortless. Now we are ready to add more features with ease and evolve the design as we go. Code is a liability. The more code we produce, the more we have to maintain. I'm very cautious when asking a coding agent to add tests for me. It usually creates very tightly coupled, mock-heavy tests that make refactoring difficult due to brittle tests. My advice for those using coding agents: Code in small steps and review the bot’s changes frequently. Slow down and think about what you're doing. What's been your experience with AI-generated tests? Are you seeing similar patterns?

Every software developer thinks “Why is the code so messy ?”, “Why didn’t the code author think about this ?”, “Why does the service lack tests ?”, “What a ridiculous variable name ?”. But does anyone go an extra mile to fix this ? 😣 😠 The answer is No. We are so busy developing new features, we accept things the way they are, & don’t work on Tech debt. This eventually slows the development. ⏲ ⏲ If you are in a similar situation, then you should definitely adopt the Boys Scout rule. Let’s understand how you can improve the quality of your software by applying this rule. 📚 📚 Boys Scout rule says - “Always leave the camp ground cleaner than you found it”. If you find mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers. 🌐 🌐 When you apply the same principle to programming, you refactor the existing code while developing new features. You work on improving the surrounding code and it doesn’t have to be a huge improvement. You shouldn’t make the code worst with your contributions. Here are few ways in which you can apply the Boy Scout rule  :- 1️⃣ Code smells - Remove redundant code, unused variables, unused imports. 2️⃣ Refactoring - Remove code duplication, improve readability and reduce complexity. 3️⃣ Test automation - Add unit tests and integration tests. 4️⃣ Documentation - Improve the comments, include more details, add run books. 5️⃣ Knowledge sharing - Share your expertise with the team and encourage everyone to follow the same practice. By incorporating these practices, you can contribute to a cleaner, more maintainable codebase and avoid the accumulating technical debt. When you apply small improvements consistently, it impact is significant and improves the overall quality of your codebase. 🚀 🚀 Let me know in the comments below what else can we include to improve the code quality while applying the Boy Scout rule. Also, if you have applied this rule in the past, share your experience in the comments. 📢 📢 For more such posts, follow me. #refactoring #codingskills #softwareengineering #softwaredevelopment

Don’t break your code during refactoring - there’s a better way. One of my go-to refactoring techniques is Parallel Change. It’s the same concept used in road construction: instead of blocking an entire street until the work is done, you build a detour to keep traffic flowing. Similarly, with Parallel Change, your code continues to function while changes are being implemented. If you’re new to this technique, start small. Practice with simple examples or katas to understand how it works. As you gain confidence, apply it to your day-to-day work - it’s a great way to develop the habit of keeping your code functional throughout the process. When dealing with modernization or legacy projects, this method proves its value even more. It eliminates the headache of fixing broken, non-compiling spaghetti code, allowing you to commit anytime and pause your work without worry. Mastering Parallel Change can make refactoring smoother, safer, and far less stressful. Give it a try - you’ll never want to go back to dealing with broken code.

I recently heard a story about Ward Cunningham coding, (Ward is one of the pioneers of eXtreme Programming, inventor of the Wiki and all-round brilliant engineer). Ward sat down with some code he’d never seen before and almost immediately started working on it. He couldn’t possibly have read and understood all that code in that time, yet he was happy to begin changing it and working towards new functionality. Getting stuff done. That’s in sharp contrast to the way many developers approach unfamiliar code. Most people are afraid to change code they don’t fully understand, and will spend a great deal of effort reading and analyzing it before doing anything. Ward’s approach is much more direct, and ultimately, faster to achieve results. In my mind, the fundamental difference is one of skill. Great engineers are not afraid to change code because they can refactor safely. Refactoring means improving the design of code without changing the externally observable behaviour. In his book Fowler describes how to do Refactoring safely and effectively - using many small safe steps to gradually transform a design from one state to a better one, without the functionality ever being changed or broken in the meantime. When you watch someone working this way it almost feels like nothing is happening, just small tweaks here and there, until suddenly you realize you have got to a much better structure with more understandable names, higher cohesion and less coupling overall. New features become easy to add once the structure is in a better state. Most developers who want to change the design will almost immediately break the functionality and/or the compilation, and not get everything working again for (best case) several minutes, or (more typically) a few hours. If you use the patterns and principles originally described by Fowler then the way you work will be qualitatively different. The code is almost never in a broken state, only for a few seconds or a minute or two at most. This is not always easy to achieve, it takes skill, but if you can do it there are many advantages: - Get started straight away even without understanding all the code. - Achieve an improved design sooner. - Less likely to introduce bugs or change functionality unintentionally. Refactoring is a hugely learnable skill and well worth the effort. It can speed up all your design work, which is, if we’re honest, the most important and difficult task developers spend their coding time on.

𝗙𝗿𝗼𝗺 𝗖𝗵𝗼𝗿𝗲 𝘁𝗼 𝗖𝗵𝗮𝗺𝗽𝗶𝗼𝗻: 𝗛𝗼𝘄 𝗔𝗜 𝗶𝘀 𝗙𝗶𝗻𝗮𝗹𝗹𝘆 𝗠𝗮𝗸𝗶𝗻𝗴 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿𝗶𝗻𝗴 𝗮 𝗡𝗼-𝗕𝗿𝗮𝗶𝗻𝗲𝗿 Refactoring keeps systems alive, but it is often seen as a cost center: slow, risky, and delaying feature delivery. That is changing. With AI (specifically Cursor) built directly into the refactoring workflow, it is no longer just about cleaning up code. It is about doing it faster, safer, and with measurable business impact. I have never been a fan of the phrase "tech debt". It makes it sound like engineers are the ones who owe something. In reality, the debt belongs to the product or platform. Paying it down almost always improves productivity, quality, maintainability, or all three. Here are four practical ways AI is transforming refactoring:  • 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝗱 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗨𝗽𝗴𝗿𝗮𝗱𝗲𝘀  AI analyzed the codebase, upgraded critical libraries, handled breaking changes, and generated migration code. Days of manual work and the risk of human error disappeared.  • 𝗣𝗿𝗼𝗮𝗰𝘁𝗶𝘃𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗛𝗮𝗿𝗱𝗲𝗻𝗶𝗻𝗴  Instead of waiting for a fire drill, AI flagged context-specific vulnerabilities such as deprecated authentication methods and provided fixes instantly, strengthening security posture.  • 𝗧𝗮𝗿𝗴𝗲𝘁𝗲𝗱 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗜𝗺𝗽𝗿𝗼𝘃𝗲𝗺𝗲𝗻𝘁𝘀  AI mapped out modularization opportunities such as splitting a monolith and even provided starter code for the new services. This enabled incremental modernization without a risky full rewrite.  • 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝗮 𝗥𝗲𝗴𝗿𝗲𝘀𝘀𝗶𝗼𝗻 𝗦𝗮𝗳𝗲𝘁𝘆 𝗡𝗲𝘁  The biggest blocker to refactoring is fear of breaking things. AI generated a suite of unit and integration tests, creating an automated safety net that boosted deployment confidence. The impact:  • Reduced critical vulnerabilities  • Modernized core systems without slowing feature delivery  • Increased developer velocity by freeing engineers to focus on user-facing features Refactoring is not just easier with AI. It now has clear ROI. It shifts from being a necessary evil to a strategic advantage. I am curious. Has your team applied AI in similar modernization work? What has been the most impactful result? #AIinPDLC #Refactoring #TechDebt #DeveloperProductivity #LegacySystems #DigitalTransformation #SoftwareEngineering

220,000 lines of code. 698 files. And 2 of those files had 15,000 lines between them.   I'm building an AI SaaS with 53 tools, 34 DB   tables, 250 Python files. The codebase grew fast but my main AdalFlow orchestrator hit 10,525 lines and my entry point hit 5,027 lines. Impossible to  maintain.    The fix: 15 step refactoring plan. One module at a  time.  Every step I follow the same discipline:  - Read the code twice before touching anything     - Write tests FIRST that fail, then extract to make them pass                     - Full suite must pass before push. Zero failures no exceptions  - CI green in clean environment or I fix it  - Rebuild staging and browser test all 3 modes  The test-first approach came from 🐍 Matt Harrison  testing methodology and it saved me more times than I can count during this refactor.                    Results:  - 8,522 lines cut from the two monoliths        - 19 clean modules extracted  - 5,419 tests passing, zero regressions        - main.py: 5,027 → 276 lines  Never let a file grow past 500 lines. Extract early or pay later.  Built with Claude and 100% NVIDIA Nemotron   stack.                              #Python #FastAPI #Refactoring #SaaS #NVIDIA #ClaudeCode

People often ask, how did we ship software projects ahead of schedule? Although not the norm, we definitely did so much more often than most. This week, I'm going to highlight some stories from the trenches: Once I was hired as a Principal Engineer for a top ten domestic retailer. Their app and backend was iterated upon by multiple engineers (they had a team of 120) for many years to great success at the outset. Unfortunately, over the past year, the mobile app, web services, and backend infra would tip over due to increasing demand from their flash sales and holiday product-led growth features. For the past six months, they had made little progress. Hardly anything was shipping, bugs or new features. After a few weeks of interviewing engineers and reviewing the codebase, we wrote a proposal and I was deployed on the project. They had a list of must-haves and a list of nice-to-haves. We basically said we would complete both buckets, but they had to agree to almost two months of refactoring. As you can imagine, one of the most stressful projects ever, but hey--I principally and theoretically knew what the entire team was avoiding and its impact. After nearly two months of *no progress* and executives breathing down my neck, we in the last month completed all of their must-haves and nice-to-haves, ranging from 3x - 5x times faster than their "estimates" or past velocity. Moral of the story -- technical debt rears its ugly head and incrementalism across many engineers has its limits. Refactoring must be part of the roadmap and when targeted and scoped to certain components of the technical architecture, will pay dividens in speed and quality. #architecture #refactoring #engineering #ecommerce #agileleadership #technicalleadership