I just got done reading an interesting and important post by David Baron of Mozilla. Although his initial focus is on the Firefox 2 browser, he makes some valid points that easily carry over to lessons learned involving software development and general project management.
The post in focus from Mr. Baron is "New Theme, Old Problem" and as titled centers to some problems with the new Firefox theme. Mr. Baron states that he doesn't "really care one way or the other about most of the changes". But what does care about are the changes done to the tabs in the new theme. Mainly that the new tabs no longer blend well from the operating system it is running on. He likes the "old way" better where:
In previous releases, the tab strip used native-looking tabs on Windows and GNOME, which have an appropriate native tab concept...I've long seen the ability to build multi-platform user interface that looks and acts native across those platforms as one of Firefox's strengths, and one of XUL's strengths, and I think improving the native-ness of the user interface is an important goal. Native user interface means Firefox fits in with the appearance and conventions of other applications, making both Firefox and those other applications easier to use.
While the discussion over the changes to the tabs in the new Firefox 2 theme is interesting...it is what he says later that caught my attention. Take a look at the excerpt below from his post and see if it catches your attention too. I have highlighted in bold the parts of his post I think are most important. Also, I want to apologize to Mr. Baron for excerpting so much of his post. However, I think what he says is important to be heard by those working on projects that it is worth repeating here at CMS Report:
I'd have complained more vocally about this earlier, except that from the moment I knew about the problem, I thought any significant design changes to the new theme would have added a significant delay to the Firefox 2 release date. This was because the new theme landed way after the feature freeze for the release, despite being a major feature. I suggested at weekly status meeting a number of weeks before it landed that it was too late, and I still think it was. Its late landing dragged a large group of developers away from what they normally work on to fixing theme bugs and probably significantly delayed the completion of Firefox 2...
One of the reasons we shouldn't take feature landings this late is that they don't have a chance to go through the normal process of feedback (including feedback after time for consideration) and refinement that is an important part of our development process. Features rushed in at the last minute are likely to do significant damage to some of the many measures of quality, even if they do improve others.
In my opinion, Mr. Baron's words contains lessons that all project leaders and developers should never forget. You can read Mr. Baron's complete post on his blog (with screenshots included) by clicking here.
Bryan Ruby is the owner and editor for CMS Report. He founded CMSReport.com in 2006 on the belief that information technologists, website owners, and web developers desired visiting sites where they could learn about content management systems without the sales pitch. Besides this site, you can follow Bryan at Google+ and Twitter.