Monday, April 28, 2008

The 'write' stuff...

Not long ago - I wrote about some frustrations with the state of software 'development'.  This morning I read an article written not too long ago "They Write the Right Stuff".  I liked it a lot.  Maybe not practical or reasonable for every piece of software (but then again, why not?) - but definitely sound techniques and processes for everyone.

The sections are

  • The product is only as good as the plan for the product.  Ah, they are talking specifications, communication, documentation...
  • The best teamwork is a healthy rivalry.  Indeed!  I've said before the best was to test your ability to recover in a DBA team would be to set up two teams - one is responsible for damaging a test database in any way they want to.  The other team is responsible for recovering from that catastrophe.  Next week - switch sides.  Not only fun but very enlightening (when I poll audiences, less than 5%, way less, have done a recovery in the last six months - could it be they might not be able to today if needed?).
  • The database is the software baseNow, they did not mean the database is the center of the application itself (I would say something like that) but rather the history, change control, reason for all change is.  The history, the legacy of the code is as important as the plan for the product.  You need to understand why things were done the way they were - in order to safely change it later.
  • Don't just fix the mistakes - fix whatever permitted the mistake in the first place.  My favorite one!  How many times will I have to hear in my life "we have to do X, but you cannot tell us to use method Y to do it - Y cannot be done".  I get that all of the time - tell me how to make it go faster, but don't look at or mention touching the application.  The mistakes are typically to be found there - in the application (typically means 99.99999999999999999% give or take a small amount).


As an aside, anyone that knows me, knows my mantra - written many times:

  • You should do it in a single SQL statement if at all possible.
  • If you cannot do it in a single SQL Statement, then do it in PL/SQL (as little PL/SQL as possible!).
  • If you cannot do it in PL/SQL, try a Java Stored Procedure.  The number of times this is necessary is extremely rare today with Oracle9i and above.
  • If you cannot do it in Java, do it in a C external procedure.  This is most frequently the approach when raw speed, or the use of a 3rd party API written in C is needed.
  • If you cannot do it in a C external routine, you might want to seriously think about why it is you need to do it...


Therefore - I just loved this Oracle-WTF.  And you know what - it pairs up with the "write stuff" article nicely.  I'll bet you that that original stored procedure was not planned (no specs), peer reviewed (no health rivalry), change managed as it was tweaked over time, and until now - never "fixed".  Can you imagine how long it took to reverse engineer that into a single SQL statement (I'd guess a minimum of an hour - and likely more).  An hour well spent, but I know personally the frustration of that person for that hour - cursing every developer that touched the code before them.

And I cannot tell you how much I hate code like this:

v_temp_runs := 0;
INTO v_temp_runs
FROM dual
FROM temp_runs );

IF v_temp_runs > 0 THEN


Why count something and do something else if there was something to be counted?  JUST DO IT, if there is nothing there - SO WHAT?

At least the original code did not end in "when others then null;" - there is that.



Anonymous Anonymous said....

I run into the select count .... if count> 0 then issue all the time at my current employer. All of the .NET developers think that raising exceptions is expensive and that counting large tables is less expensive. I guess a large table for them is > 100 rows. They just don't get that they need to do some performance testing.

Mon Apr 28, 04:40:00 PM EDT  

Blogger Joel Garry said....

"It may not be sexy, it may not be a coding ego-trip -- but it is the future of software."

We can all dream, anyways.

"But the impression Larson got was that engineers didn't seem too concerned about how well the finished software actually worked."

That sounds about typical.

"The group has one customer, a smart one. And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations."

Let's see how many copies of Oracle Fusion you can sell at $350000000 a pop.

Word: ezfyzt

Mon Apr 28, 05:51:00 PM EDT  

Blogger Gary Myers said....

"The B-2 bomber wouldn't fly on its maiden flight -- but it was just a software problem"
Can't find any support for this.
talks about low pressue in a fuel line and residue on a heat exchanger.
Perhaps the story needs some more testing.

But in support of the theme, the most reliable application I've worked on was for deployment in a submarine. It wasn't a safety critical app, but the simple fact that it CAN'T be patched (for weeks at a time) meant it had to work.

Tue Apr 29, 02:18:00 AM EDT  

Blogger Paulo said....

Hi Tom,

I think you meant to write:
- but definitely sound techniques and processes for everyone.

Tue Apr 29, 04:17:00 AM EDT  

Blogger Thomas Kyte said....


thanks! you were correct


... These include corrections of minor software and
hardware deficiencies, ...

that seems to support it.

Tue Apr 29, 06:26:00 AM EDT  

Blogger scubajim said....

In the Navy on aircraft carriers there are people who guide the landing aircraft in. The pilots trust them because they are also pilots. They switch off. (landing on an aircraft carrier is very stressful)

Tue Apr 29, 11:58:00 AM EDT  

Anonymous AJ said....

Tom said in part
"Don't just fix the mistakes - fix whatever permitted the mistake in the first place."

Reminds me of one of my favorite interview questions to get asked
"How do you feel about being on call"
To which I always reply
"I do not mind being on call and I do mind being called. What I hate is being called for the same thing more than once. So when I fix it, I fix it so it stays fixed".
That response always seems to result in a smile from the interviewer.

Tue Apr 29, 01:02:00 PM EDT  

Blogger Warren McCall said....

This line from the NASA software developers article really hit home:

"The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."

I spend at least 50% of my professional life trying to drill this concept home to development teams. Unfortunately, proper design seems not only to be not taught in CS classes, but is actually scorned. "Ahh, don't worry about design, it just slows you down!" seems to be the credo for many development shops these days. I'm glad houses, bridges, medical equipment, etc. aren't built this way!

Tue Apr 29, 03:53:00 PM EDT  

Blogger Joel Garry said....


It was the B-1 that was delayed by avionics software problems (cf Risks 9.47 ), but
google ZSR-62 .

word: dbvmxtn

Tue Apr 29, 04:22:00 PM EDT  

Anonymous Anonymous said....

Never underestimate the value of code reviews. I was involved in a large embedded telecom software project that was getting way behind schedule. A new software manager was brought in to get us back on schedule. He started by slowing everything down and having everyone do a presentation on the current state of his code, including a line by line review. After that we put in place a very strict release process with automated testing and code reviews for every release.

The project got back on track and, I believe, shipped to customers sooner than it otherwise would have had we not put a lot of process in place.

I also learned a lot about what I was doing wrong in my software. Having a team of critics look at my code line by line was invaluable.

Tue Apr 29, 05:04:00 PM EDT  

Blogger LewisC said....

I once looked at a developer's code that did pretty much the same thing. A convoluted query to get a count and if the count was > 0 they ran an update. I asked why do the count and the answer was that the update took a long time so they wanted to save time and resources when the count was zero.


Sometimes a head shake just doesn't express the appropriate emotions.


Wed Apr 30, 10:02:00 PM EDT  

Anonymous CarlW said....

"All of the .NET developers think that raising exceptions"

I think that you are missing the point - the only thing that exceptions are is exceptional. Do not use exceptions to shape the flow of anything - if there is a possibility in the normal everyday execution of a procedure that:

SELECT name INTO v_Name FROM table;

will result in no_data_found then it is not an exception, and as such should not be treated as one.

Fri May 23, 06:03:00 AM EDT  

Blogger khalid said....

Which one has better performance, calling a java stored procedure from a pl/sql store procedure or a pl/sql stored procedure from another pl/sql stored procedure?

Mon Jul 25, 03:24:00 AM EDT  

Blogger Thomas Kyte said....


how do you think I would answer that question about performance?

I would set up a benchmark to evaluate it...

But my experience tells it - it will be plsql from plsql - unless the java procedure can do what the plsql procedure does only MUCH (orders of magnitude) faster. Which can happen but would be rare...

Mon Jul 25, 09:09:00 AM EDT  


<< Home