Antonio, I have to say, there are a lot of very good reasons not to use “…the most abstract/declarative/high-level language or tool you can and still be performant.” A few that come to mind are: declarative may not be the best way to go (SQL itself was supposed to get rid of programmers, right?); available expertise may not be; performance may be overridden by maintainability, including the possibility that getting locked into a tool may diverge from Oracle’s direction (many examples of tools that were cool in the 90′s and suck now are out there); the marketing fluff I referred to, which may have many other names like paradigm-of-the-day; some tools don’t show that they suck until you scale up; some tools may simply be overwhelmed in the market by Oracle’s tools or other herding effects; some paradigms suck; and so on.

Never lose sight of the goal of the design.

It’s difficult to get paid to program if you get fired.

Sometimes the dumb way is the better way.

It is extremely rare to have a system in isolation. Deal with it.

Don’t fall for marketing fluff.

Use the level of bleeding-edginess appropriate for the business.

The direct contradiction is that you if you want to reuse something you have to expose it. The price of reuse is lower encapsulation and higher coupling. In Steven’s example the tradeoff is a no-brainer, but if we’re going to extrapolate a general rule out of that we need to be aware that this is a careful balancing act. Sounds a bit pedantic, but I have seen many systems fall into this trap.

For example, hard-coding the value of pi all over the place is a bit silly. Putting it into a constant in a header file is much better. But having our financials system hit a web service API on our LMS application to retrieve its value for pi is even sillier than hard-coding. So we’re better off accepting a bit of repetition and just defining our own pi.

So, yes, these are excellent rules, but as is so often the case, their truth is not a simple truth.

And yes, I totally endorse your rule #8. It never ceases to amaze me how many talented application developers go to pieces when confronted with a simple ETL problem. PL/SQL guys are no doubt much more in the groove, but general app developers need to be much more comfortable with data.

Oracle PL/SQL programmers must like data, otherwise maybe they should switch to some other programming language that is not database centric.

On the other hand, I see your point that as programmers we are more interested in coding rather than data.