I recently answered this question on Quora. I feel I came across a tad more aggressive than I intended. I think it’s clear I’ve had some pent up frustration with the Joomla project and community.

There’s also a little back and forth between myself and Amy Stephan (Quora | Twitter) in the comments of this answer as well which flesh out my opinion on the current state of Joomla and where the project is lacking.

It’s frustrating because I really liked where Joomla was headed originally. I honestly didn’t believe that forking Mambo was the best long-term idea, but it gave the project a huge initial push from an enthusiastic community who was eager to make something of the stagnate Mambo project.

After an initial burst of code and some major releases advancement seemed to wane and it’s been very nearly 3 years since the last major release (1.5). In that time projects like Drupal, ModX, Expression Engine, and many others have blown past and are maintaining good momentum and seeing steady community growth.

I feel many developers simply aren’t very excited about working on Joomla, and I feel it’s the Mambo fork that is to blame. While it did give Joomla a great burst of users at the start, the horrible job of refactoring Mambo into a more modern platform is far more laborious than it’s worth.

Also it’s not just old code that hurt Joomla, but rather old, outdated site management metaphors inherited from Mambo. Most people aren’t publishing old style news site portals anymore. We’ve long left the days where things like PHPNuke portals were commonplace.

Amy maintains that the forthcoming 1.6 release will “leap frog” projects like Drupal due to its long incubation. It remains to be seen if this will be the case, but I wish them all the best - the more options that exist in the open source CMS arena, the better.

My latest post on the Fenix Solutions blog about Microsoft’s growing support for PHP and several high-profile open source projects.

An old article from Joel Spolsky, but one that offers some timeless advice to all developers and product managers.

Actually, my title is wrong - it should say “Don’t Rewrite WORKING code, Refactor”.

Like Joel says, developers have an automatic urge to destroy an unfamiliar codebase and re-build software in their own image. Part of this is simple ego, but mostly it comes down to an important point - “Code is easier to write than to read”.

When you see a constructor for a piece of business logic consisting of 368 lines littered with seemingly random, mis-placed calls to the database, and, god-forbid, UI generation, the first instinct is that the codebase is un-maintainable and you’d be better off starting over.

This is almost always a horrible mistake. If you’re dealing with a long-lived codebase that WORKS, it works BECAUSE of those horrible assaults on programming paradigms. Joel reminds us that that constructor is the way it is likely because of bug fixes - months or even years of real-world use exposed edge-cases not considered by the original developers. By scrapping working code and starting over, you’re not just throwing out working code, you’re throwing out the invaluable knowledge of these edge cases.

This is something I’ve personally struggled with over the years. I have ancient code kicking around on hard drives and live sites from the past that has plenty of “WTF was I thinking!?!?”s in it. I have seriously considered tossing the whole thing in the garbage and starting over but have resigned myself to the idea that the more efficient use of my time is to refactor that codebase little by little to better support new features.

By the time I catch up and “break even” in terms of a functioning product by starting over, I’d have likely already implemented dozens of new features and made significant improvements to the old codebase instead.

Old code isn’t necessarily bad code, just misunderstood.

This is an excellent post and something I think a lot about when it comes to instituting metaphors in a piece of software.

While it is often helpful to build on a user’s prior knowledge via the use of an interface or workflow metaphor (the excellent example given in the post is that of calculator apps), these metaphors may ultimately cause developers to lose sight of the fact that we aren’t bound by the rules of the physical world and a large part of the reason we use digital systems is because of this fact.

Trying to balance implementing familiar patterns while leveraging the power of software is probably the toughest part of developing a top-tier user experience.

We’re often told that we should design our websites and software to mimic real-life objects. The iPhone strengthened this idiom, and Apple has been driving this home hard for the iPad.

But it’s not absolute, and it’s not always the best idea. My favorite counterexample is the typical calculator…