Re: Agility and Data Design (was: Dreaming About Redesigning SQL)

"Mike Preece" <michael_at_preece.net> wrote in message news:1b0b566c.0310232104.1acc58c4_at_posting.google.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message news:<Mv%lb.5734$9E1.26853@attbi_s52>...
> >
> > Well, it sounds like what you're describing falls into the category of
> > what I was describing as smaller homogeneous systems, where I
> > said it "may work well enough."
> >
> Yes, maybe. What would your upper limits be for a "smaller homogeneous
> system"? Maybe it would be best to use number of users, annual
> turnover - that sort of thing - to measure by, as (and I'm really not
> trying to provoke by saying this) the number of "transactions",
> "records", "tables", "total database size", number of IT staff, total
> IT expenditure and required hardware will all be smaller on an
> equivalent Pick system.

Fair enough. But that's hard to do; clearly, how much use a system gets is independent of how complicated or hard to develop it is. Metrics like "how many pages is the requirements doc" spring to mind, but then you have to control for the authors of those document, so that's quite difficult.

Clearly, heterogeneity is easy enough to identify, though: if all the apps are written in the same language, then you've got a point of simplicity that makes your life easier.

You've ruled out number of tables, but how about number of attributes? Would that be comparable?

Also, I think number of developers is a reasonable metric, even if it is lower for Pick systems. The reason I care about this is if System A can only grow up to 10 developers but System B can grow up to 100, then there will be some jobs that can only be done in System B (given some specific time constraints,) even if System A is twice as efficient as System B with 5 developers.

I dunno; a lot of these issues are measurable, but only at a cost of hundreds of thousands of dollars.

Marshall Received on Sat Oct 25 2003 - 10:52:33 CEST