In my regular web browsing, I came across a great post from Sara J Chipps entitled “Your Code Sucks.” As she talks about deleting code that sucks and restarting from nothing, something sounded amazingly familiar:

After some growth I encountered code that I thought sucked ever so often. At this point I wasn’t decimating things all together, I would find specific parts of code that I found intolerable and rewrite it. About 9 times out of 10, when I got more than halfway there I’d run into an issue that made me say “Ooooh, that’s why they did it that way” and revert it or use the same “sucky” logic with my syntax.

It was familiar because this is how web2project started.

In late 2007, when the dotProject leadership announced a rewrite from the ground up, we were faced with a choice: a) we could work on the complete rebuild and lose the lessons learned from the past 7 years of development OR b) we could attempt to refactor and cleanup the system to make it stable and useful.

We chose the latter and in the nearly three years since, we’ve worked to do just that.

Yes, we’ve found lots of code that “sucked” and usually we’ve been able to remove and replace it without negative repercussions. This has closed dozens of bugs, eliminated numerous behavior oddities, and has often given us significant performance improvement. More importantly, we’ve been able to maintain a fully functional system throughout. Unfortunately, we’re nowhere near complete. There are places – like the infamous projects_list_data function in the CProjects class – where replacing the logic has proved difficult and seemingly impossible at times.

Regardless, to find and track down these problem areas, we use three different strategies that could work on any project:

  1. First, we use various PHP quality assurance tools. Each gives us a different look at the system and can identify potentially problematic areas.
  2. Next, we actively encourage external Code Reviews. Sometimes questions from someone who doesn’t know our history and reasoning can offer a new and useful perspective.
  3. Finally – and most importantly – we take an active role in our Support Forums to determine who is having problems where and work to determine why.

Do we find them all? No, but we’re regularly working and exploring to find and eliminate more.

Can we use help? Yes, because none of us have all the answers or even necessarily the best strategy to combat the issue.

Can you help? Yes... just remember the Ten Commandments of Open Source.