Of project management and faceted failure

Consider this:

I am developing PLASTIC, a system for EXTROVERT-domain users.

The specification states PLASTIC shall use terms from vocabulary set BENIGN within domain EXTROVERT.

BENIGN has a structure I do not understand.

Should I a) try to generate a structure I can import into PLASTIC directly from the XML of BENIGN, b) implement BENIGN XML directly in PLASTIC or c) import an unstructured, flat version of BENIGN into PLASTIC?

From the point-of-view of the users, it is necessary to view the content in BENIGN using its contextual structures. Importing BENIGN without this creates a situation where BENIGN is basically useless.

From the point-of-view of development, the existing PLASTIC API imports hierarchical term sets, but BENIGN isn’t structured like this because BENIGN terms are atomic and its “hierarchy” is a loose taxonomy that supports terms belonging to multiple classes.

Adapting PLASTIC to support BENIGN would take time, while coercing BENIGN into a PLASTIC-compatible hierarchy would be relatively simple, but would require understanding of BENIGN’s structure.

BENIGN gets imported flat because it makes PLASTIC support BENIGN as per specification, even if it makes a mockery of how BENIGN is supposed to be used. This is especially clear when one considers that the complexity of BENIGN lies in the combinatory aspect that also gets ignored because PLASTIC doesn’t support it.

This is a sad and true story.

Posted in Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s