A few weeks ago at the PHPBenelux Conference, I gave my presentation on the rebirth of dotProject as web2project where I covered one way of rebooting a project. But after catching Elizabeth Naramore’s talk on “Technical Debt” again, it got me thinking..
Within web2project, we made the deliberate decision to work on our technical debt. Even after 2 major, 5 minor, and one patch level release, we still occasionally find issues ranging from annoyances to things that will require major refactorings*. Either way, since we’re steadily documenting them, we’re constantly getting a better picture of the state of the system and its strengths and weaknesses.
Alternatively, we could have trashed the code and started from scratch..
The classic example is Netscape 5.
In the 4.x series of Netscape (circa 1997), they had a successful product with high market share but behind the scenes, the underlying code was “a mess”. It was difficult to extend, expand upon, fix, and do all those great things developers know and love. It was the classical technical debt dilemma.
To solve the problem, they put a basic support team on Netscape 4.7.x and dedicated everything and everyone else to rebuilding the system from the ground up as Netscape 5. Weeks, months, and even years passed and the Netscape community was split. You could continue developing for Netscape 4.x which was known to be a dying product or you could develop for Netscape 5.
No wait, Netscape 5 didn’t exist yet.
Despite the best intentions, Netscape killed their community. Their product lines were completely stationary while a little company called Microsoft picked up market share with Internet Explorer 5.0, 5.5, and then 6.0. As much as we (now) hate IE 6.0, it was the only viable option out there for years. Regardless, even with Internet Explorer hitting nearly 95% market share, Netscape 4.7 was still out there. It was still under active use.
Ignoring a problem doesn’t fix it.
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!?”
And frustration leads to the Dark Side.
When you consider tossing your code and starting over, at first glance it seems like a great technical option. You get to go back and do things the “right” way. You get to architect it the “right” way. You get to put those great concepts in from day one instead of grafting them on later. It’s a beautiful notion and sounds like a great idea…
Unfortunately, unless you get the replacement out there quickly, you run a risk of killing your organization. Your competitors have months (or years) to catch up and pass you. Your bugs and feature lists sit open indefinitely. But worst of all, your community is stuck somewhere between a dead project and a non-existent one. Where do they go?
It’s the worst of all worlds.. and entirely avoidable.
* The scariest problem is our project_list_data function with Cyclomatic Complexity of 145 million.. which is down from 195 million. It “passes” data in via a series of globals and “returns” data the same way. Don’t worry, we’re working on it.