Chosing a platform depending on criticality
Robert Byrne writes:
Read your article on PHP vs. Java and you stated that PHP is good if the '...loss of data isn't fatal...'. I was wondering what you ment by that and if you could give an example of such a thing happening that would be great because I've never heard of such a thing.
No problem, Robert.
Different projects have different levels of criticality, which is basicly a way to define the cost of error in a given project.
Different kinds of criticality
In projects with low criticality, such as a small content management system or community discussion boards, the cost of error is small. If there's a bug that causes data loss, such as the system rejecting a discussion post because it contains invalid characters, it's not a big problem. You fix the bug and move on.
Data loss on projects with low criticality functions in a way as a testing aid. When you loose data, there's a bug. It's not worth testing every minutia.
In projects with medium criticality, such as an invoice system, the cost of error rises, but it's still possible to revert any problems that bugs create. When the system sends out a wrong invoice, the customer complains, the bug can be fixed, and a new invoice is send.
Projects with medium criticality generally require you to restore the situation after fixing the bug. It's not enough to fix the bug and then say by-gones.
In projects with high criticality, such credit card processing, it's very expensive to correct errors. If a bug causes every tenth transaction in the VISA processesing computer to round the numbers wrong, it'll be dfficult, time-consuming, and expensive to patch the wrong-doings of the bug.
High criticality projects must pay great attention to avoiding bugs because they're so costly to correct.
In projects with extreme criticality, such as nuclear reactor control systems, space shuttle launch programs, or pacemaker, bugs can be deadly. The user isn't likely to be around if a serious bug slips by.
Projects dealing with life or dead criticality needs to pay an extreme amount of care to how they handle the development process. Few measures to prevent bugs from slipping by will be deemed too expensive.
The above is largely based on principle four of the seven general design principles of methologies in Alistair Cockburn's Agile Software
Development detailed on page 151-153
Picking a platform based on project criticality
And it goes straight to the language debate with the question of what kind of platform you should pick to support a given project depending on criticality.
PHP certainly qualifies for projects of low criticality. Many projects have low criticality and hence will do good with PHP. It's more debatable when you move above low criticality. With strong care and forceful resolution, PHP can probably also serve projects of medium criticality. It'll require you to do a lot of work yourself, though, building mature testing frameworks that are already available in high quality for Java.
In examining criticality, as in most every thing else, it's important to pick a platform that offers the right amount of bug prevention, detection, and correction at the right price.
