Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 18 Jun 2006 09:26:38 -0400
Message-Id: <0u0gm3-0qp.ln1_at_pluto.downsfam.net>


David Cressey wrote:

>
> The problem with application developers is that they tend to fall into the
> trap that says that their application is the center of the universe. The
> problem with database designers and DBAs is that we tend to fall into the
> opposite trap. We tend to think of our database as the center of the
> universe.
>

<snip>

>
> Strategic data planners need to avoid all three traps.

I think the trap takes very different forms for the two parties.

Application developers believe they can code their way out of anything, and therefore the app should be the redoubt, the safe port in a storm. They can't consider the database in this role because they think of it as passive. A programmer who, in his own mind, is wisely planning for an uncertain future, will trust to his code, which he can do anything with at any time.

But what is the form of the trap for the database designer? Here the pattern seems to be a focus on prevention of mistakes which, while laudable, can become a paralyzing refusal to change. I've heard db guys say "You can't do that" far more than I've heard them say, "That's a toughie, but let's see what we can do."

Strategic planners in my experience usually do not have the technical expertise to make any such decision. What comes into play is a kind of political version of Conway's law, the architecture is congruent to the political structure of the development team.

And finally we can see why so many architectures are code-centric. Simply put, when the MBA who's looking at a big sale throws down an impossible fantasy to the team. The database guy says, "No way, that breaks all my rules" and the programmer says, "I'll do it!". The MBA always goes with the guy who says he'll do it. In the end it is often inelegant, took longer than they thought, does less, but, and this is a big but, it satisfies the customers minimal requirement and is productive and profitable for them. Cash flows and business progresses, and the programmer gets a promotion.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Sun Jun 18 2006 - 15:26:38 CEST

Original text of this message