I have an idea, borne out by first-hand experience, as to why
database-backed software development efforts so frequently fail.
Let me be clear that I'm including here those projects that may
not be documented as failures, but take much longer to roll out
and deploy than originally planned because of the need to perform
a major 're-write', 're-architecture', or 'tuning' effort.
Personally, I call these delayed projects 'failures': more often
than not they could have been completed on schedule (or even
The single most common reason for failure is a lack of practical
knowledge of the database — a basic lack of understanding
of the fundamental tool that is being used. The 'blackbox'
approach involves a conscious decision to protect the developers
from the database. They are actually encouraged not to learn
anything about it! In many cases, they are prevented from
exploiting it. The reasons for this approach appear to be FUD-
related (Fear, Uncertainty, and Doubt). They have heard that
databases are 'hard', that SQL, transactions and data integrity
are 'hard'. The solution — don't make anyone do anything
'hard'. They treat the database as a black box and have some
software tool generate all of the code. They try to insulate
themselves with many layers of protection so that they do not
have to touch this 'hard' database.
This is an approach to database development that I've never been
able to understand. One of the reasons I have difficulty
understanding this approach is that, for me, learning Java and C
was a lot harder then learning the concepts behind the database.
I'm now pretty good at Java and C but it took a lot more hands-on
experience for me to become competent using them than it did to
become competent using the database. With the database, you need
to be aware of how it works but you don't have to know everything
inside and out. When programming in C or Java, you do need to
know everything inside and out and these are huge languages.
Another reason is that if you are building a database
application, then the most important piece of software is the
database. A successful development team will appreciate this and
will want its people to know about it, to concentrate on it. Many
times I've walked into a project where almost the opposite was
A typical scenario would be as follows:
- The developers were fully trained in the GUI tool or the
language they were using to build the front end (such as Java).
In many cases, they had had weeks if not months of training in
- The team had zero hours of Oracle training and zero hours of
Oracle experience. Most had no database experience whatsoever.
- They had massive performance problems, data integrity
problems, hanging issues and the like (but very pretty screens).
As a result of the inevitable performance problems, I would be
called in to help solve the difficulties. I can recall one
particular occasion when I could not fully remember the syntax of
a new command that we needed to use. I asked for the SQL
Reference manual, and I was handed an Oracle 6.0 document. The
development was taking place on version 7.3, five years after the
release of version.6.0! It was all they had to work with, but
this did not seem to concern them at all. Never mind the fact
that the tool they really needed to know about for tracing and
tuning didn't really exist back then. Never mind the fact that
features such as triggers, stored procedures, and many hundreds
of others, had been added in the five years since the
documentation to which they had access was written. It was very
easy to determine why they needed help— fixing their
problems was another issue all together.
The idea that developers building a database application should
be shielded from the database is amazing to me but still the
attitude persists. Many people still take the attitude that
developers should be shielded from the database, they cannot take
the time to get trained in the database — basically, they
should not have to know anything about the database. Why? Well,
more than once I've heard '... but Oracle is the most scalable
database in the world, my people don't have to learn about it,
it'll just do that'. It is true; Oracle is the most scalable
database in the world. However, I can write bad code that does
not scale in Oracle easier then I can write good, scaleable code
in Oracle. You can replace Oracle with any technology and the
same will be true. This is a fact — it is easier to write
applications that perform poorly than it is to write applications
that perform well. It is sometimes too easy to build a single-
user system in the world's most scalable database if you don't
know what you are doing. The database is a tool and the improper
use of any tool can lead to disaster. Would you take a nutcracker
and smash walnuts with it as if it were a hammer? You could but
it would not be a proper use of that tool and the result would be
a mess. Similar effects can be achieved by remaining ignorant of
I was recently working on a project where the system architects
had designed a very elegant architecture. A web browser client
would talk over HTTP to an application server running Java Server
Pages (JSP). The application logic would be 100 percent generated
by a tool and implemented as EJBs (using container managed
persistence) and would be physically located on another
application server. The database would hold tables and indexes
and nothing else.
So, we start with a technically complex architecture: we have
four entities that must talk to each other in order to get the
job done: web browser to a JSP in the Application Server to an
EJB to the database. It would take technically competent people
to develop, test, tune, and deploy this application. I was asked
to help benchmark this application post-development. The first
thing I wanted to know about was their approach to the database:
- What did they feel would be the major choke points, areas of
- What did they view as the major obstacles to overcome?