Bert Scalzo on optimizing PL/SQL coding practices

http://www.orafaq.com/node/846

This article show how PL/SQL tools can be used to engineer "better" PL/SQL code, and notes some scary statistics about poor coding practices, and suggests that professional programmers may someday be held accountable for the costs of PL/SQL coding errors:

One survey estimates that inferior software engineering and inadequate testing in 2002 alone cost $59.5 billion for the just US. Now I've seen current quotes of about 2.5 million information technology (IT) workers in the US. Moreover it seems like only about 1/2 of those working in IT these days designs and writes code - so that translates into nearly $48,000 in bug costs per PL/SQL developer.

What if companies someday legally held programmers accountable for costs based upon their mistakes (don't laugh, it's been discussed before and why programmers might need to unionize). Because I for one would not want to see my salary reduced by that figure!

Of course that's really just some interesting observations and speculation. Closer to earth, the facts break down as follows:

Developers spend 40% of their time fixing software defects

Between 60% and 70% of the cost of software is attributable to maintenance.

In short, developers simply and generally spend too much time and money fixing bugs.

Mr. Scalzo shows some areas where PL/SQL can be quality controlled:

Reliability
- Do we have the ideal set of best practice rules identified
- Is everyone following all the prescribed rules all the time
Consistency
- Is everyone interpreting all the rules the exact same way
- Will different people apply the same rules to different ends
Measurability
- How do we measure and attribute success of this methodology
- Can we quantify the cost versus savings of this methodology
Effectiveness
- Will we simply and easily get results of better engineered code

Mr. Scalzo also explains how tools such as TOAD's CodeXpert technology can help automate PL/SQL code reviews and concludes:

There probably is no such thing as the perfect program. Nor should we expend inordinate resources in attempting to achieve such a lofty goal. But that does not mean we should forgo producing quality code when and where we can - especially when there are both proven techniques and tools to assist us in that endeavor.
If we can simply embrace and employ superior project management and sound software engineering practices, PL/SQL programs can easily be made much more readable, maintainable, effective (i.e. correct) and efficient.

Furthermore if we utilize world class development tools (like TOAD) that facilitate such efforts, we should be able to more quickly and easily produce world-class code - which should require less time and money both initially and on an on-going basis. All of which should lead to greater customer, manager and programmer satisfaction.

��