Re: Reminder, blatant ad

Todd wrote:
> dawn wrote:
> > Todd wrote:
> > > 1) You think that throwing data control (I mean real life 'facts' here,
> > > not bits on a hard drive) into the domain of the developer (who is a
> > > person that really has no connection with the data) is a good thing.
> >
> > Perhaps we need to define developer. I am calling anyone who is
> > developing software a "developer." Perhaps we need to define software?
> > It is everything "stored on" a computer that is not hardware. Does
> > that work for you? That would be "soft stuff" that can change,
> > compared to the hardware. I haven't thought long and hard about that
> > definition, but that is how I perceive it.
>
> What works for you then? Flexibility or stability?

Yes. And the needs for each must be taken into account when assessing risks. Sometimes there is a need for such incredible stability that you would not want to risk any instability for a little flexibility. You still would want optimal flexibility within your extreme stability, however.

> Can we achieve
> both? Don't get me wrong. I think you are flexing some good muscle.
>
> >
> > Some parts of this software could be like propositions that can be used
> > as input or output, while other aspects of this software could be
> > functions that operate on input to produce output. But it's all
> > software.
> >
> > > In other words,
> > >
> > > Me: 'Hey, developer, build me a sandwich'
> >
> > --d: smile when you call me that
>
> Coincidence. D was supposed to mean Developer, not Dawn. Sorry about
> that if you took it that way.

Ah, yes, I misinterpreted, but since I'm from the developer side of the house (if we must choose sides), that read OK.

> > > D: 'OK, I can do that, what do you have in the fridge?'
> >
> > --d: how hungry are you? are you a vegetarian? do you prefer whole
> > wheat? Does anyone else need a sandwich? ...more attempts to ascertain
> > requirements.
> >
> > > Me: 'I don't know, go look at it and figure it out. Oh, and here's a
> > > knife if you need it'
> >
> > --d: at this point I tell you to make it yourself, but I'll play along
> >
> > > D: 'Hmm, OK I'll do my best. Did you want mustard with that? Maybe
> > > you might want to know if somebody else wants mustard? Wait a second
> > > ... is there somebody else?'
> >
> > I know I'll often miss something in spite of considerable efforts in
> > requirements elicitation, but hopefully not something that big.
> >
> > > Me: 'Well, that's not important right now, is it?'
> >
> > Sure it is. I might have to be careful how much of the cheese I use up
> > on your sandwich.
>
> Well, I suppose I was getting at the fact that it seems that some of
> what you suggest screams lack of data integrity,

I understand why you say that. There is more than one way to achieve data integrity, however. There are also many different aspects to data integrity. A system designed to handle only the "most prevelent color" (or some other attribute) rather than a list of colors because that would be less expensive is sacrificing data integrity, perhaps with a good business case for doing so when the DBMS doesn't support attribute lists.

> and in trying to get
> that point across, I dropped into a client situation (the dialog above
> would have me as the client) which is frequent in any kind of database
> design. I was simply trying to say that some of what you suggest may
> be putting a scarier load on the developer.

Yup, I followed your reasoning.

> Chaos where something
> should be stable. Initial condition: client gives you bad data, or no
> data; client gives you bad metadata; Result: chaos gives you a terrible
> headache as everything may spin out of control. Sensitivity to initial
> conditions, you get the idea...

I understand that different things are scary when choosing different toolsets. There are tradeoffs.

>
> > > 2) You seem to sing 'convenience' in many of your posts (under the
> > > hoods).
> >
> > Productivity for software developers as users of various tools. If you
> > call that convenience...
>
> Productivity. What is that exactly.

More, better, faster. An individual or team is able to accomplish more with less, for the long haul.

> I assume you mean that developers
> make money for a small amount of time spent, ease of maintenance of
> software, blah blah. Well, at this point, I still need some
> convincing.

I would expect as much.

> > > Personally, and perhaps unfortunately, I think we can't always
> > > be convenient when it comes to modelling reality.
> >
> > No, but we can usually improve on user experience and productivity when
> > we decide those are important.
> >
> > > 3) It's almost like you're trying to say that RM is this thing that we
> > > have to 'put up' with.
> >
> > In fact, I think it is something that we DON'T have to put up with ;-)
> >
> > > You could be correct in a 'convenient' way, but
> > > wrong in a 'correct' way. Think about it.
> >
> > Oh, you know I do.
> >
> > > 4) Keep up the discussion. I enjoy it immensely. I'll certainly be
> > > perusing your blog every now and again.
>
> BTW, this was not meant as a jibe.

No problem at all -- I didn't take it that way.

> I really am interested in what you
> have to say.

Much appreciated. Thanks. --dawn

> > Thanks, Todd. Cheers! --dawn
> >
>
> Todd
Received on Sun Jan 29 2006 - 20:50:34 CET