Subject Wolves and IB-Architect
Author Jim Starkey
I would like to explain a few things about how I operate on this
list. As all of you are aware, I designed, created, and directed
until from its founding in 1984 until we sold it Ashton-Tate in
1991. Between that time and early this year I stayed in contact
but watched from a distance. As a result of the events of late
last year and the involvement of a family member, I have become
active again. All in all, I have another project on which I would
much rather be working. I am on this list out of a sense of
responsibility towards Ann, InterBase friends, and the InterBase
customer base. For the record, I don't work for InterBase and
I don't have stock in InterBase-IV.

Between the time I left InterBase there are been a number of
architectural changes that I applaud, such as SuperServer and
the transfer of DSQL from the client to the server. There are
also some changes (and extensions) that I consider ill-advised
and need revisited. The code base is a little ratty in places
but completely servicable.

Between the time I left InterBase and the present there has been
a great deal of turnover in the engineering organization. Charlie
Caro, InterBase employee #14 (15?), is the sole survivor. Although
the architecture is largely as I left it, the culture has changed
somewhat. Some of the engineering heritage has slipped into folklore
and some has disappeared completely.

One piece of culture lost in the general Borland/Inprise emphasis
on secrecy is that major changes used to be discussed generally, openly
and critically within the entire engineering group. On a project
as large and complex as an RDMS different folks have different
perspectives and sensitivities and may notice problems overlooked
by others. This is good. Defending a proposal in front of a
critical audience leads (sometimes indirectly) to better design and
to better understanding of the design.

I see my role as mentor to budding architects and as a link to the
post, explain both how things work and why they were designed the
way they were, and sometimes to point out why what was a great idea
in 1981 is a lousy idea in 2000. It is not my role to censor bad
ideas. I would much rather take a new idea, roll it around a bit,
and steer it toward something useful.

When anybody makes a proposal of the list I try to give it
serious consideration. If I see problems I prefer to express
them as questions rather than criticisms, though if some explanation
is necessary, I'm as like as not to just launch in. Sometime
my questions are just questions. However, when my questions,
particularly the "how do you handle..." type, are ignored or
muddled over, I tend to get a little testy. I don't like having
my time or the time of others on the list wasted. And I don't
like the intellectual laziness implied by a half baked idea
promoted as a jewel for somebody else to polish. But when a
legitimate technical objection is passed over as a product of
"bias", I get downright ornery.

In the interest of full disclosure, there are two other things
that bring out fangs and claw: Solutions looking for problems and any
attempt to cut off debate other than consensus. And, ah yes!,
statements like "OK, it doesn't work. What else is wrong with it?"

There are infinite ideas out there and only finite problems. If
we can work through the ideas to find the ones that solve the problems,
the rest is just a matter of coding. It's not like we're trying
to bring peace to the Balkans...

So let's treat each other ideas and criticisms fairly. If somebody
has taken the time to respond to a proposal, please consider the
comments and respond appropriately. If somebody misunderstands
your comments, maybe you weren't clear, maybe his perspective
is different, and maybe you're just plain wrong. If you can't
take the time to respond seriously, you'll never know which.

Jim Starkey