On the Intracto blog there's a new article posted from Jeroen Moons with some suggestions you can use to pay down technical debt in your legacy code through a bit of effective refactoring.

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 gives lost of different suggestions for things that can be done to "save your code" and make it not only easier to maintain but more flexible:

• Persuading the customer
• Don't replace [a huge mess] with a new one
• Make problems visible
• Fight what hurts most
• Build a library

There's plenty more great suggestions here too with some thoughts and methods to back them up and help you accomplish them in your own code. If you're suffering through a large legacy codebase from day to day, I highly recommend reading through this article.

Keith Casey has an interesting new post to his site looking at a common dilema among development groups - whether refactor or rewrite is a better option for the state of the current codebase when it comes time for a change.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.

For those PHPers in the Atlanta area, there's one upcoming event that you don't want to miss - the 100th meeting celebration of the Atlanta PHP User Group (September 6th)!

We’re proud to announce that we’re celebrating our “100th Monthiversary” – our 100th monthly meeting – on Thursday, September 6th from 6pm to 9pm! We’re planning a cookout with plenty of social time and will have Kevin Roberts presenting Pecha-Kucha style on the eight and a half year history of our group followed by Elizabeth Naramore as the featured speaker presenting on “Technical Debt”. We’ll also have a number of special guests from the greater PHP community, including group founder Ben Ramsey, Cal Evans, and others.

There'll be plenty of food, tech talk and giveaways at the event - not to mention Elizabeth Naramore's excellent "Technical Debt" talk. The prizes will include IDE licenses, books, gift cards, and the grand prize – a Nexus 7 tablet! Keep tuned to the Atltanta PHP site for more information as it comes.

Thanks to an initial article from Brandon Savage the topic of code commenting has been floating around the PHP community and several members have taken the opportunity to express a few thoughts of their own:

• Brandon Savage's blog entry kicking off the discussion by noting that not commenting the code is the "accrual of technical debt".
• In his blog post Marco Tabini mostly agrees with Brandon's comments with one difference - he suggests that correct code doesn't need comments.
• Dagfinn Reiersol takes a more pragmatic approach to the issue and wants to see the code before making a decision on whether the comments are needed or not.
• Benjamin Eberlei reinforces this refactoring idea and suggests staying away from ambiguous names and unclear code practices.
• Richard Thomas notes that comments have their place but they don't need to be taken to either extreme.
• Rob Allen's opinions on Benjamin Eberlei's thoughts
• Brandon Savage's reply to all of the criticism he's recieved over his initial post

Posted any thoughts or comments of your own on the subject and do see them here? Let us know!