Migrating to Joomla 1.6

I carried out a quick test to establish the issues in migrating to Joomla1.6 on my local PC. The simple answer is that one shouldn't jump into it if one is not willing to do a considerable amount of work oneself. I used a basic site which used rhuk_milkyway template. Here are the findings:

The JUpgrade actually works quite smoothly if you are converting from Joomla 1.5.22. It successfully creates a new working environment for Joomla1.6 and preserves the 1.5 installation. Basically a new directory is created to hold 1.6 code and the MySql database gets the additional Joomla tables with j16 prefix. In ideal world it should just be required to drop the old tables and directory and point to the new installation. However the life is not that simple.

Firstly, the default templates which Joomla1.6 comes with are not production quality and rhuk_milkyway is not supported. Originally it was envisaged to include this particular template in the production release but the idea was shelved. The net effect is that various menus just disappear as one has to place them in new positions manually. Also the menu items had a value of -1 set in line Link Type Options/Link Image for various menu items. All these had to be manually set which is annoying and cumbersome.

After spending around an hour I had a functional site but it was a crude replica of the 1.5 version. I was not too fussed about extensions at this stage but obviously their availability is a critical decision in choosing to migrate. To get the site fully working I would have been forced to spend a considerable amount of time on CSS. So the bottom line is : "Don't rush in! Access control lists are great but the effort required to migrate is too much at this point in time".

Estimating project delay just from the quality of requirement specification

I was privileged to attend a course by Tom Gilb recently on quality and he produced a wonderful way of estimating project delay from just the quality of its requirement specification. Those who are not familiar with Tom should know that he is the pioneer of iterative development method. His Evo methodology with emphasis on weekly deliverables and feedback was produced in the 60s, a long before Agile and Scrum appeared on the horizon. Also he can be credited with introducing software metrics in the 70s which were incorporated as Capability Maturity Model level IV. People who have grown up in quality movement are familiar with the fact that the quality is something which has to be designed within a process and cannot be gained through mere inspection. So just by checking the number of defects in a random page of the specification we can estimate the probability of project success.

A logical page of around three hundred words is inspected for deviation from the rules like testability, ambiguousness and no-design by 3-5 people. It is no good saying that a quality like usability should be dramatically improved unless we numerically quantify it. We take the figure for the highest number of major defects discovered by a team member, D. We multiply this by a factor of two to establish the discoverable defect density (source: experience). Now any inspection only captures a third of the potential defects (source: Capers Jones) so we multiply the discoverable defect density by a factor to generate potential major defects. Now the likelihood of a major defect turning into a downstream bug is one third. Each of this downstream bugs will cost 10 hours to resolve. This gives the formula for project slippage as:

Hours slippage = D * 2 * 3 * 1/3 * 10 * number of non-comment logical pages in the specification

Now this is pure magic as it has been empirically validated on a number of projects in the field. If you don't believe it then carry out the test on a project on which you have worked in the past and see whether the slippage provided by the formula is not within plus or minus 10% of the actual slippage.