This is the Database Programmer blog, for anybody who wants
practical advice on database use.
There are links to other essays at the bottom of this post.
This blog has two tables of contents, the
Topical Table of Contents and the list
of
Database Skills.
Today I am taking a huge detour from technical matters to lay out the
philosophical groundwork behind this blog. The ideas presented today
lie beneath every essay on this site. It is easy to observe that people
seem driven to formulate absolute truths to guide their pursuits.
Programming is no different, programmers are driven to find the
absolutes that will universally guide their efforts. Those absolutes
are not that hard to find, if you know the method for seeking them
out. Fortunately, we have hundreds and thousands of years
of human efforts, both successes and failures, to draw upon when
embarking upon the task.
Absolutes in the Post-Modern Age
Academics refer to our current stage of history as the "Post-Modern"
age. Thinking in the post-modern age is dominated by a
deep mistrust
of the very concept of absolute truth. Many thinkers have noted
that in the post-modern age the only absolute is that there
are no absolutes. Now, anybody who has not
bothered to read much past what they are handed likely believes
much of this without even thinking about it, they may not know that
in the history of the human race such thinking is less than 60
years old.
But that "no absolutes" stuff is all nonsense at
best and downright cowardice at
worst. If you want an example of an absolute truth, try stepping
off the edge of a cliff: even if you do not believe in gravity,
gravity believes in you. It is an absolute truth for me that if
I do not take care of my customers my life becomes unpleasant.
It is a further absolute truth for me that I constantly obvserve
programmers proclaiming absolutes (always use relational, always
use OO, etc). When I stop observing it, then I suppose it won't
be an absolute anymore (and I suppose then it never was?)
So let us now cheerfully ignore the wailing of those who cry
that there are no absolutes, and ask if we might discover some
elements of software development strategy that hold true always
(ok, maybe mostly always) for the
context of database application development.
Aristotle and Virtue
Nowadays nobody has to read philosophy much anymore, at least not where
I live (in the United States), so most programmers have never heard of
a man named Aristotle, who lived about 2500 years ago. This is a shame,
because Aristotle had a logical way of thinking about things that
would warm the heart of any programmer.
One of Aristotle's major contributions to civilization was his
formulation of what philosophers call "virtue". Philosophers use the
term in a technical sense, and they do not use "virtuous" to mean
"nice" or "pleasant" or "good-natured." To a philosopher (or at least
those that taught me) something is virtuous in Aristotelean terms if
if performs its function well. The standard classroom example
is that a virtuous table serves the function of a table, and a
virtuous table maker is somebody who makes good tables.
This is a very useful concept for programmers. If we want to speak
of a "virtuous" program, we mean simply one that meets its goals.
This takes the whole high-minded theory and philosophy stuff back
to real down-to-earth terms. (This is why I always preferred Aristotle
to Plato).
In the quest for the absolute, if we let the ancient philosophers
guide us, we discover the surprisingly basic idea that our programs
should perform their functions well if they are to be called
virtuous. This is easy to swallow, easy to understand, and
easy to flesh out.
What is a Virtuous Computer Program?
A virtuous computer program is one that serves its purpose well, and
so we need to flesh out the three purposes that are common to most
programs:
- To meet some institutional or strategic goal of those who
sign the checks (or accept the work as charity in some case).
- To meet the goals of end-users, which almost always comes down
to performance and ease-of-use.
- To provide income for the developers (or meet their own goal of
providing charity work for non-profits).
Notice what is not on the list, things like ensure all data resides
in a relational database, or implement all code in strictly
object-oriented languages. We are not nearly ready to consider
such specific strategies as those, they are completely out of place
here in a discussion of the unifying goals of all projects.
So let's review. So far we know that the
absolutes of programming are the pursuit
of virtue, which turns out to be a fancy way of saying that the program
should perform its functions well, which turns out to mean simply that
it should do what the check-signer asked for, in a way that is workable
for the end-users, and at a price that keeps the programmer fed.
This leads us towards strategies for reaching those goals.
The Virtuous Programming Strategy
Continuing with the idea that a virtuous program meets is basic
goals, we can say that a virtuous strategy smooths the way for
a programmer to meet the basic goals.
An unvirtuous (or just plain bad) strategy
litters the path with obstructions or ends up not meeting the
goals of the check-signer, end-users, programmer, or all of the
above.
Before we can begin to formulate a strategy, we must look next
at the reality of the programming world. Some of the fundamental
realities include (but are not limited to):
- The end-user or check-signer may not fully understand or
be able to articulate their requirements.
- The programmer may not correctly understand requirements,
even when correctly articulated.
- In a healthy prosperous situation there will be new
requirements that interact with established requirements
in ways that range from no interaction at all to
fiendish incompatibilities.
- The world will change around you, creating demands that did
not exist when the system was created (some of us can still
remember when there was no internet).
- Staff will come and go.
- ...and so on.
So even before we begin formulating particular strategies for particular
situations, we recognize that our strategy had underlying goals it
must facilitate, such as:
- Being easy to change, both for correcting mistakes
and adding features.
- Being able to maintain and sort out possibly contradictory
requirements that arise as the years go by.
- Requiring little or no "deep magic" that depends on arcance
knowledge of employees who may depart.
- Being able to expect the unexpected (like the explosion
of the web etc.)
Only after we have worked through to this point can we begin to
evaluate specific strategies and technologies. We can now begin
to ask about the proper context of the database server, where to
use object orientation, and if javascript is a good programming
language. Anything that responds to our core goals and realities
can be considered for use, anything which does not play into the
core goals is useless at best and obstructive at worst.
Future essays (and some past essays) in this series will refer
back to these ideas. For example, many developers have observed
over the years that if you "http://database-programmer.blogspot.com/2008/05/minimize-code-maximize-data.html"
>Minimize Code and Maximize Data then you gain many advantages
in terms of development time, robustness, and feature count.
Other ideas similar to this will come out over and over in future
essays in this series.
Conclusion
The strategies and techniques that you will see on this blog are
all aimed at one way or another towards the goals expressed in
this essay. At the very beginning comes the goals of the
check-signer, the end-users, and the programmer. From there we
seek strategies that will satisfy our need to grow, change,
correct, and adapt. Only then can we ask about the technologies
such as databases and object-oriented languages and see how
well they let us meet all of these goals.
Related Essays
This blog has two tables of contents, the
Topical Table of Contents and the list
of
Database Skills.
Other philosophy essays are:
