On Mon, Nov 28, 2011 at 5:15 PM, Alexander Johannesen
<[log in to unmask]> wrote:

Hi,

First, I should apologize for my tone a bit. It's been an odd day,
and, yeah, email. Sorry to be overly flippant.

> Understanding this is not disconnected from designing data models
> *right*. It's the same thing. By extension I should mention that
> people are terrible at telling you what they want or need, but they're
> good at telling you what they hate. If nothing else, I'd suggest to
> tap into that wonderful hate.

I think we're probably actually talking about the same thing with
different language. Understanding what people want doesn't fall under
the purview of what I think of as 'data modeling' -- I imagine data
modeling as being quite limited in scope.

So, if data modeling involves understanding actual business needs and
making them possible, than I agree completely. But it sounds a bit
like saying 'everything follows from user interaction design -- but of
course you need to represent your underlying data somehow' ;-)

There are lots of facets to building software, and representing data
structures is just one of 'em.

>> But an 'all flows from data modeling' thought process leads to FOAF,
>> FOAF leads to hate, and hate leads to suffering.
>
> This sounds suspiciously like someone who don't understand the perils
> of data models and how they affect all the FOAF and hate that's built
> up around its faults. FOAF and suffering is a symptom of shitty data
> models, not shitty code. Unless you've got a little more meat on that
> argument? :)

You're exactly right -- my beef with FOAF is that it's a detailed data
model written for a need that didn't particularly exist. I'd argue
that a better data model wouldn't help it, as the concept is flawed.

My stereotype of the 'think of the data model first' approach is lots
of time spent developing a data model that solves a need I think might
exist, but actually doesn't. I've built software like this and it made
me sad.

-n