How we got here: optimism through failure

February 15, 2010

After our Feb 12th meeting with the Boris an McQ, there was unanimous agreement among our team members that we had finally reached a suitable project plan.  The scope of our project had been narrowed from a daunting 20+ services to a much more manageable “several”.  Our primary source of optimism was not the promise of less work, though.  Instead, our optimism resulted from a shift in the type of work we would now endeavour to complete.

Our initial plan of documenting twenty-odd services was quick to demonstrate the deficiency of our Eclipse knowledge.  After creating a basic service template and using it to create initial documentation for a handful of services, Stefan and I reluctantly asked a painful question:  “How is our work different from the (pretty mediocre) documentation which already exists on the e4 wiki?”

Of course, the answer to this question is that it’s not…yet.  Until our last meeting, we had expected to solicit widespread community contributions to fill out our documentation and compensate for our lack of e4 expertise.  In this way, we were to produce in-depth documentation without ever needing in-depth knowledge of what we were documenting.  But our meeting forced us to confront a problem with this plan:  In spite of being engaged and knowledgeable, the Eclipse community would need more than our passive requests to involve itself with our project.

With neither adequate knowledge nor a method to easily obtain it, it was clear that we needed a new game plan.  During our Feb 12 meeting, it quickly became clear that this plan would include a narrowed scope and greater focus on documentation design.  That is, from the diametrically opposed properties of quantity and quality, we had chosen the latter.

Producing high quality documentation for a small number of services solves our knowledge problems on two counts.  First, the narrowed scope allows us to devote more of our limited time to learning about each service.  Instead of shotgun approach to information collection, we can actively (aggressively?) solicit one-on-one communication with developers who know about the services we are interested in.  Second, an increased focus on format allows as to divert some of our efforts from information collection to knowledge creation.  In this way, our final deliverable will not be evaluated solely on the completeness of its information.  Instead, the quality of the method by which  we convey information will equally represent value to the Eclipse team.


One Response to “How we got here: optimism through failure”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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

%d bloggers like this: