Date: July 20, 2003
From: DCJ
To: Editor
I have been in the computer field since I started my career way back in '85. My
understanding and application of database theory is largely due to the 3rd
edition of INTRODUCTION TO DATABASE SYSTEMS (C.J.Date). (E.F.Codd's
original articles in CACM are the other treasures I keep). I still have the
copy of the book in my shelf and quite often I refer to it and get a lot of
insight. To add to this collection I have PRACTICAL ISSUES IN DATABASE
MANAGEMENT and your website.
I work in financial services industry with a big database to support the
business operations. Time and again we spend days fixing data quality issues.
For some time I have convinced myself that the way we have built the
applications is wrong.
There is no quality in the people and processes we specify to
automate. There is a serious lack of software engineering methodology. When I
started looking at the dbdebunk.com I was more convinced of my knowledge and
tried to explain it to my colleagues and the bosses that the data models, and
table designs they do are fundamentally wrong. And that there are database
books/articles that explain the data fundamentals succinctly. And it is time
that we applied these principles.
All the time they finish the conversation with a remark such
as "It is all theory man. In practice we don't have to stick to them. Text
book ideas don't work in practical world!” I had such a frustration that all my
colleagues, when I disagree with them, dub me as having an "attitude"
problem.
These are the folks that have gone up the ladder with such
titles as "Enterprise Architect", "Application Architect",
"Database Architect" (and "specialists" in each of these
categories!). They are so called because they are tools specialists.
Whatever they do, they do it with a tool. For example, if they want to
understand the business processes they want a process-modeling tool. If they
want to understand the data and relationships, they want a data-modeling tool.
What if they want to list down the tasks? Sure, they want a project management
tool. They need tools for developing code. Tools for everything!
In such a setting the fundamental principles are a casualty!!
Sure, the folks at the top of the ladder who promote them are no less dumb than
these. It is sad to see that a good team of developers is led by people with no
formal computer education. And that is a curse on the IT industry as a whole, I
think.
From: Fabian Pascal
To: DCJ
You are describing accurately not just the reality at your
company, but for the entire IT industry and, I may venture to say, the US
business culture in general.
This is a society that prides itself on being
"efficient" economically, but thoroughly violates the foundation for
efficiency: knowledge. Efficiency requires that vendors and buyers be fully
informed, yet the IT industry not only does not reward scientific knowledge and
education, but it actually punishes them via marginalization, as you found out
yourself when you would not conform. This is instilled in people in not less an
effective way than the soviet system was instilling its doctrine (I know,
because I ran away from there). Given this culture, nothing else should be
expected from database practice.
People who are not taught how to think/reason for themselves
find it hard to do so and avoid it by reliance on tools; in turn, tools are
created to stop them from thinking. This "cookbook approach" is now
corrupting even academia, whose main function is precisely to combat this, but
has succumbed to industry pressure too.
Here is one of favorite pronouncements on the matter by one
of the smartest there was:
The ongoing process of becoming more and more an a-mathematical society is more
an American specialty than anything else (It is also a tragic accident of
history).
The idea of a formal design discipline is often rejected on account of vague
cultural/philosophical condemnations such as "stifling creativity";
this is more pronounced in the Anglo-Saxon world where a romantic vision of
"the humanities" in fact idealizes technical incompetence. Another
aspect of that same trait is the cult of iterative design.
Industry suffers from the managerial dogma that for the sake of stability and
continuity, the company should be independent of the competence of individual
employees. Hence industry rejects any methodological proposal that can be
viewed as making intellectual demands on its work force. Since in the US the
influence of industry is more pervasive than elsewhere, the above dogma hurts
American computing science most. The moral of this sad part of the story is
that as long as the computing science is not allowed to save the computer
industry, we had better see to it that the computer industry does not kill
computing science.
--E. Dijkstra
Posted
09/26/03
[ABOUT]
[QUOTES]
[LINKS]
