The Intracto.com blog has a post sharing some ideas and methods about how to rescue legacy code through refactoring. In it author Door Jeroen Moons shares from his own experience working with legacy applications and offers practical advice you can apply in your own legacy codebase to "tame the beast".

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: your project can be saved.

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there is a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

He starts by defining technical debt and the idea of "code cancer", those shortcuts and hacks that are taken during development and slowly corrupt the quality of the code. He then covers one of the harder parts of refactoring - persuading the customer that it's an effective use of time. He also mentions replacing current code with quality code, making problems visible, working on the hard parts and code ownership. The post finishes up with mentions of testing for quality and functional assurance, creating reusable libraries and isolating and replacing things a piece at a time.

In a new post to his site Marco Pivetta talks about "visual debt" in your code. "Visual debt" is described in this video as the difficulty in understanding caused by complicated code.

Today we're talking about Visual debt in our code.

As an introduction, I suggest to watch this short tutorial about visual debt by @jeffrey_way. The concept is simple: let's take the example from Laracasts and re-visit the steps taken to remove visual debt.

The code example the post starts with, while a working piece of code, leans towards being more complex than necessary to complete the task. Marco spends the rest of the post walking you through the simplification of this code. He shows how to remove pieces that aren't as necessary, refactor it to remove the enforcement of contracts and some further things you can do to simplify the code.

He ends the post by saying that his suggestions are all sarcasm on his part and shouldn't be followed. By removing things like return type hinting and functionality that enforces good behavior you risk odd issues and poor usage down the line.

On SitePoint.com's PHP blog today there's a recent post looking at technical debt - what it is, how to locate it and how to help mitigate (and prevent) it in the future.

On the one hand, technical debt refers to the quick and dirty shortcuts we take and the effect they have on future development. On the other hand, technical debt is also about the things that we don’t do, such as not commenting our code, not developing documentation, not doing proper testing, etc.

They're looking at things from more of a financial standpoint than a development view, but some things are similar between them. Having some technical debt is almost unavoidable, but having a lot is a bad thing. They discuss how it relates to the quality of the product/codebase and three strategies for dealing with debt:

• Don't ignore it
• Triage it correctly and realistically
• Impose a debt ceiling and schedule regular time to work on it

Anthony Ferrara has written up a great post on technical debt, relating it to terms that might be a bit more "real world" for many out there - corresponding financial problems.

Lately, I've found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it's a very powerful tool that -- when used wisely -- can be a great asset to any team. It seems to me that most of the people that I've been talking to really don't agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I'd share my opinions, and see what you think...

He talks about a few different kinds of technical debt described by the names of their financial counterparts:

• the Payday Loan (a current concession for the sake of time)
• a Mortgage (making small parts, payments, of a whole without consideration of the overall picture)
• a Credit Card (not knowing the need causes a sub-optimal solution)
• Hidden Debit (an unclear understanding of the full scope of the debt)

He also touches on two other topics - how to find and get rid of the Hidden Debt your project might have and a common misconception that technical debt doesn't exist in an aglie world.

In a recent post to his site Keith Casey mentions something that should be obvious to most software developers (and managers of developers out there) but is easy to forget - technical debt doesn't just disappear, even if the related resources change dramatically.

Just because you set a codebase aside and do it the "right" way, your problems don't disappear. The same bugs that annoyed people yesterday will be there today and tomorrow. In fact, when the bugs are still there a week, month, or year from now, they move beyond annoyances and into frustrations as people think (or say) things like "this has been broken for years.. why haven't they fixed it!?"

He notes that, while tossing the entire codebase out the window and starting over again (a move very, very rarely shown a good idea), you'll still end up with issues - this time involving resources and the work needed to sift through all of the bugs in the new code.