My first intertwingularity sightings

In 1996, I became the solo project team member at the conclusion of a large software development project.

While our other developers, our functional analysts, and technical analysts all went on to other projects, I stayed on full-time to provide maintenance support and to further enhance the software.  And here I still am today, continuously honing my skills, continuously improving my performance, always learning something new.

It took me until last fall to realize that my greatest challenges, starting in 1996 and to this day, all have something to do with "intertwingularity".  I knew it as soon as I saw the definition of the word, which I found haphazardly on Wikipedia.  (Well, kind of haphazardly.  Something for some other post someday ...)

Back to 1996 ...

On the project, our analysts were using a software project that involved creating deliverables: many documents that described the software functionality to be developed, which clients would sign-off to say "yes, that's what we want."  (I've got opinions on that.  Yet more material for some other post ...)

And then the rest of the team left.  And they left me with a few problems:

• no context-sensitive help for the software
• no end-user documentation (that was up to the users to create)
• all of these documents to maintain, to keep in sync with software changes/enhancements, to make available, with no instructions/process left behind to guide me going forward
• no process and no software
• to handle change requests
• to track what I'm working on
• to track what is pending and what is done
• no process to let users know "what's new" when releasing software updates
• how to make sure there aren't multiple versions of the same information sitting in inboxes, local drives, and network drives; some of that information possibly very out of date

There.  My first intertwingularities:

• an intertwingled (i.e. complex, highly interrelated and cross-connected) list of problems to solve
• and, the thing in common with all of the problems individually and combined: intertwingled information related to different aspects of the software and the project.

Double the pleasure, double the fun?  At the time, more double the stress, double the headache.  It would take me about 10 years to find a terrific solution.  (Again, the makings of a future post ...)

In future posts, I hope to discuss other examples (or types?) of intertwingularities, in addition to these two three:

1. a problem (or a grouping of related and intertwingled problems) that is complex because of the number of intertwingled projects and project "things" involved
2. a large amount of information that is "deeply intertwingled"
3. various intertwingled purposes/goals of information.

Huh.  Kind of wordy, but maybe not so bad for a first post ...