Re: Is programming sexier than data design?

Frank says:  "You have to do a lot of programming to make up for  
crappy data design."

Boy, howdy.  Or just the subtleties of humans in the loop who enter  
the information, or are upstream creating tools and don't actually  
read or understand the data design.  Real cases, S1000D related for  
real world examples:

1.  The folk creating the Data Module Requirements List (DMRL)  
containing the Data Module Codes (DMCs) are SharePoint/Excel folk.   
The DMCs are "ugly" because they have dashes in them; so they take  
them out.  The codes are stored in the data module reference element  
as attribute values.  Programmer has to put them back in (think Split  
function).  An implementation detail, but... or they load the code  
values with commas without reckoning with comma separated value data  
formats internal to a compiled tool downstream.  Again, an  
implementation problem so solvable (schlepping HTML tables internally  
or creating special format classes is ugly but reliable).

On the other hand...

2. Logistics "expert" who creates the codes never reads the S1000D  
specification and doesn't know that the codes are validated as  
patterns.  He removes the subSubsystem code because "he doesn't like  
it".  Because the codes serve as filenames and as ids internally, he  
breaks the namespace all the way across the project.

3.  Because of bad process design (same person or persons doing both  
and fully ignorant of the XML Schema requirements because they can't  
read them), specs all of the tools to use the bad design while  
reducing the actual process of the XML creation and editing to  
"messing with the ASCII".  He then runs the project for six months  
with these hidden flaws.  Every bit of information in the project  
relies on these codes, they are disseminated widely as is and they  
have never been through an XML validation pass.  Not once.

Oopsie.

What the programmer faces is not simply bad data design, but bad data  
design, incompetent processes, hidden code, hubris and arrogance.   
Humans in the loop who do not and will not accept that a specification  
that relies on XML to deliver is inherently an XML specification and  
that claiming they can do their jobs without knowledge of XML are  
walking the beaches heads up, proud and smiling just before the  
tsunami.  The only wall between them and the roaring sea is a  
programmer.

Caveat vendor.

len