Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Live Hideout
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Don't Call Me a Coder!
 
Internet Identity Workshop: May 12-14, 2008
 
Design for Interoperability: Is It Like the Weathe...
 
OOXML+ODF: ISO Steps In
 
Unburdening Overwhelm: Covey and Peace of Conscien...
 
Dreaming in Code: The Long Tail to My Little Ecco
 
The Unbearable Overwhelm of Technical Debt
 
Public Availability of Standards
 
On the Giving Away
 
Interoperability Principles, I: IE8 Rising

Don't Call Me a Coder!

Recently, an acquaintance phoned me, looking for some advice about business-service software (for CRM and those other TLAs) and the APIs that some packages and services have.  He says to me, "You're a coder, aren't you?"

I felt myself bristle, as if I had been insulted and dismissed all at once.  My chum, an IT and training guy that I know through our wives, had a problem he thought someone with coder chops would understand.  Neither of us really knows what the other does, but we quickly got over that little speed-bump enough to have an useful conversation.  It was vaguely clear what he was looking for and he had some casual idea that I was the sort of bloke who would know about Application Programming Interfaces (APIs) into hosted business-service software packages.  He wanted to know more about how (and which of) those could be used to integrate a system the way he wants it for his business.

Indeed I do know a bit about APIs and integration, but I have no domain knowledge abut business-service integration generally and his application specifically.  Still, I was able to ask questions and do a little digging around on my own.

So what cheeses me off about "coder?"

Let's back up a little.

This month, May 2008, is the 50th anniversary of my first line of code.  It was in Fortran [I on an IBM 704], it compiled, it ran, and it blew up with a "divide check" on the first and obvious test case.  ("Divide Check" was a hardware halt in those days, so I effectively crashed the machine with a division by zero.)  I was employed as an engineering aide in Renton, Washington, and my engineer and I were teaching ourselves Fortran from the manual.  This little program was one that I had made up myself as an exercise.

In 1958, coders might have been thought of as interchangeable with programmers and software developers as we now think of them, but coder was also a particular job classification for some. 

In the beginning, coders were often human compilers of the designs created by others.  This was not a tribute to creativity, since the creativity is presumably in the detailed and specific design, handed down on the '50s version of clay tablets: the computer-program flowchart.  In this context, a coder would not know the requirements or the problem being solved or even understand the method of solution.  The idea is just to code the logic using the available language of the machine (at whatever level it is).  Thus was code-and-fix mindless development begat.

Now, I have in fact worked with code where the flow-charts were created by Grace Murray Hopper, and that is interesting for its own sake.  Fortunately, I was not the coder.

The need for coders in this sense disappeared with the availability of better hardware and good software-development tools, even ones for machine-language assembly.

It is not as if there aren't still efforts to routinize and deskill big chunks of software development.  That is what is pejorative about "code monkey."  That this is happening at all is a great misunderstanding on the part of the erstwhile code monkey and even more-so on the part of the IT (even ISV?) management that thinks this is a successful way to develop robust application software (ideally by eliminating programming altogether and begrudgingly sending code monkey work off-shore in the meantime).  Those who think that any sort of automated, model-driven development is going to eliminate the need for "coders" have a surprise coming.  The amazement will be around how does one test, debug, validate, and then maintain, upgrade, re-engineer, refactor, and re-integrate those beasts.  I can't wait to see what the Total Cost of Development and Deployment audits will reveal as the return on those investments.

So I never cottoned to "coder."  And I never did it.  I cannot recall any time in my career, not even that first time, when I ever coded in the sense that it was meant then and in whatever sense it is meant now. 

I have written code, but that is not the same.  Writing code is, as you might suspect, an increasingly small part of what I do, even when I am the sole developer on a project.  There is actually something odd about that.  I very much enjoy developing little programs, yet I find that my attention is usually consumed by other aspects of delivering an architected, well-crafted result.  In particular, the problem these days, as Fred Brooks noticed over 20 years ago, is not knowing how to code but knowing what to code and knowing what is important in the coding [1].

You can call me an architect as long as you're smiling when you say it.

You can call me a cybersmith all you want.

 
Comments:

 
Dear Cybersmith, nice piece. I, too, want to see real data on Total Cost of Development and Deployment. Until we're reguarly measuring that I don't think there will be much progress on understanding exactly what it takes to build reliable and robust software-based systems.

And you can call me a "socio-technical systems engineer" ... for now.

-Bill

# posted by  Bill Anderson: 09 May, 2008 07:16

 

Post a Comment

Internet Identity Workshop: May 12-14, 2008

I'm a big fan of the Internet Identity Workshop, having attended three previous ones.  Some of my snapshots from those are here on Flickr.

IIW 2008a, the first 2008 workshop is happening next week at the Computer History Museum in Mountain View, California.  We are just past the pre-registration discount date, but registration is still open.  Also, the first day, Monday afternoon, May 12, can be attended for free.

There's an extended description of the event on the IIW Wiki.  I must tell you that the open-space format of these workshops is superb and inspiring.  (My absence this year has to do with some serious financial retrenchment and learning to live like self-sufficient retired folk, not out of a lack of interest.  I must carefully focus my energy and any subsistence on immediate projects as I progress through my 70th year.)

There is additional information in posts from the three organizers (or "conveners" as I am learning to say): Identity Woman Kaliya Hamlin, Technometrian Phil Windley, and Mr. Vendor Relationship Management, Doc Searls.

There is much activity in the social-networking world that impinges on requirements for user-centric identity and digital identity.  You've heard about OpenID, Information Cards, and maybe Liberty Alliance and other approaches.  This is the place where folks who are keenly interested in having digital identity work for everyone gather, mingle, and choose what conversational and collaborative itches need to be scratched at the moment.  You can bring your itch here and find some fellow scratchers.  There is a seriously-open, welcoming format and approach.

As an example of the far-reaching interests that come under the IIW tent, Jerry Fishenden just posted on issues of digital identity in civil matters.  And an excessive interest in identity by various parties (not just the UK government) is a common topic, including in today's disturbance about the Washington Post on-line comment policy. 

The nexus for these conversations as well as the nuts-and-bolts of digital identity and identity-system interoperation is IIW, the IIW Wiki, and the Identity Commons umbrella.  Plug yourself in.  Use an OpenID to do it.

Design for Interoperability: Is It Like the Weather?

As part of the February 21 announcement of the Microsoft Interoperability Principles, there were promised developments around fostering a community of interest regarding interoperability. 

One activity, the Document Interoperability Initiative, promised in February 21 remarks from Bob Muglia, was kicked off on March 6 with some roundtables.  Microsoft Interoperability Evangelist Craig Kitterman is spear-heading this activity.  The only accounts I've found are on Kitterman's blog and a recent forum post.  So far, the activity is not very visible, with Kitterman gate-keeping the conversation.  It is not clear how this activity will open up at this point, or even if that is a desired direction.  I remain hopeful, since this is my primary focus on interoperability (along with document-processing/-management middleware).

Another activity, the Interoperability Forum, had a web page with promised initiation on March 20.  On that day, the three MSDN Forums on Interoperability were announced.  The three forums provide interesting coverage:

• Interoperability Conversations
  for general discussion and questions on interoperability
• Technical Interoperability Scenarios
  for discussion of scenarios of Information Technology importance
• Achieving Interoperability through Standards
  as a place to have questions answered

There's more "you-have-questions, Microsoft-has-answers" than I expected to find in the introductory materials and the thrust of the descriptions for each forum.  I sense that there is a preference for bilateral communication rather than community discussion.  Yet it's a start, and I am hopeful, visiting regularly from the first day. 

I'm impatient.  It's been less than a month and the Interoperability Forums are terribly quiet.  As often happens when an MSDN Forum is quiet and is on a general or generic topic, it attracts misfires:  questions and requests for assistance that are pretty far off from the topic (at least, as I understand the topic).  The supporters of the forum have been very gracious in assisting posters and suggesting places where they can find an appropriate technical community for further assistance.  I've started posting, but I don't know what to offer that finds a responsive-chord in others who have interoperability concerns.

I worry that these forums might not achieve a critical-mass of participation and community.

Is interoperability something that people talk about, expect to be provided, and yet no one does much about it?

I have this long list of possible barriers to thriving of the Interoperability Forum;

• It is a backwater of the MSDN Forums which is far more oriented to folks who have immediate technical difficulties and want support (from peers or Microsoft experts).  [For perspective, go to the entrance of MSDN Forums and scroll all the way down to the end where Interoperability has been tacked on.  Look at the kind and quantity of forums and the statistics that follow the listing.]
    
• People don't like being required to obtain a Windows Live ID.
   
• There are ways in which the MSDN Forums don't work very well (the RSS feeds do not show posts on threads, the alerts system doesn't identify the Forum, and there are other glitches).
    
• It is Microsoft operating in a very Microsoft-centric place in a very Microsoft-centric way.
    
• People working on interoperability of products are hesitant to have public conversations about it.
    
• Achievement of interoperability is a private matter and is tightly held to protect product differentiation and competitive advantage.
    
• Interoperability is seen as a necessary evil and only dealt with under duress if at all.
    
• Developers presume their tools and the products they use are interoperable and support interoperability by default, addressing integration problems bilaterally when they arise.
     
• Interoperability is an externality and everyone wants someone else to deal with it at no cost to them?

I could hand-wring further.  I am not surprised that people are protective of their efforts to exploit interoperability (or not), and maybe that's all there is to it.  And maybe, like me, people are having difficulty figuring out how to begin an useful discussion in the midst of their more pressing "get our stuff working" concerns.

So, rather than rend my clothing and wail dramatically, I need to figure out how to be patient here and also find ways to contribute that encourages the participation of others.   I'm frustrated by that, yet what else is there to do?

One calibration point: In a web search on "interoperability" I notice that Microsoft announcements are prominent, followed by standards-development activities, government initiatives, with consortia and academic activities as well.  Along with some companies that promote interoperability as a business or product focus, there are some odd links to organizations having the word in their name but whose only actions to foster interoperability are apparently rooted in a belief that interoperability is an automatic benefit of killing Microsoft in the European Union.  My general impression is that activities tend to be focused and industry based, involving big players.  I wonder if Technorati will come out differently?

[update 2008-04-16T16:01Z: My Technorati search for use of the tag "interoperability" did find a gem that was unknown to me:

Sam Rosenbalm: The Challenges of Interoperability.  (web log post) Microsoft on ISVs, msdn.com, 2008-04-15.  This post ties in the Microsoft-supported Interoperability Vendor Alliance as a pro-active forum for establishing and confirming interoperability at various levels.  Rosenbalm also exhorts readers to take advantage of the Interoperability Forum.

My inclination had been to dismiss the IVA as an advocacy or business-alliance sort of organization.  I under-estimated how much there is active support for interoperability arrangements.  I'm unsure how the identified "Interoperability Labs" work at this point.  Of course, all of these arrangements have Microsoft technology involved in some way.  I don't mind that so much.  I would like to see where there are counterparts for the other major suppliers in our industry, such as Sun and IBM and also any sort of open-source coalition.  I am interested in the constructive cases as opposed to victim-centric ones that presume interoperability as an automatic outcome of destruction of any dominant player or business model.]

 
Comments:

 
Dennis, one possibly fruitful thread might be to start a conversation about the many levels of interoperability, perhaps starting with work practice and going deeper into middleware and system support. Kind of like a network stack, except starting from the top - from the world of work practice and process.

Langdon Winner pointed out that there are three aspects of technology: apparatus, technique, and organization. Perhaps this kind of description is helpful for interoperability.

-Bill

# posted by  Bill Anderson: 16 April, 2008 10:14

 

 
Dennis, thanks for the insightful post. Sorry it took a week to comment. On the Document Interoperability Initiative - there is a lot of work going on now to expand the scope of these engagements. I will be updating my blog with some more details this week with details on upcoming events. Next week at Interop Las Vegas we will also be discussing some specific efforts that we are kicking off in response to feedback we have already received in the Boston and Seoul events. Finally, we will be launching a new page on www.microsoft.com/interop that will more formally document these activities moving forward. I look forward to discussing this further to get your feedback on how we can make these events (and the overall initiative) more useful for the ISV and Developer communities.

# posted by  Craig Kitterman: 22 April, 2008 00:56

 

Post a Comment

OOXML+ODF: ISO Steps In

Clippings from the nfoWorks Diary on recent events of possible wider interest to standards geeks and armchair torch followers:

2008-04-09 ISO/IEC SC34 Takes Over OOXML

ISO/IEC Joint Technical Committee 1 (JTC1) Subcommittee 34 (SC34) held a plenary meeting in Oslo, Norway on April 5-9.  Alex Brown provides a comprehensive report.
   SC34 proposes to create ongoing activities to carry out its responsibilities:
        1. IS 29500 (OOXML) maintenance
        2. IS 26300 (ODF) maintenance (pending OASIS agreement)
        3. Harmonization (with a proposed work-item expected from the DIN NIA activity)
   To start things off, two ad hoc working groups have been created. 
   The first ad hoc working group will propose how IS 29500 maintenance should proceed, producing a proposal by 2008-09-01, one month prior to the next SC34 meeting.  This ad hoc group is chaired by Alex Brown who will lead a two-day meeting in London this July.  Participation is from SC34 member bodies and I take it that ECMA TC45 members are invited to chime in.
   The second ad hoc working group is being created to capture technical comments on IS 29500 and make sure existing analysis is not lost.  Within 90 days (by July 2) there will be a mechanism in operation "to compile a list of comments on ISO/IEC 29500 received from NBs, liaisons, and the general public" and then to "publish the on-going list as an open document on the SC 34 website."
   In the resolutions from the meeting, I note that the final text of DIS 29500 has already been created.  SC 34 requests distribution to its members no later than May 1.  I don't know what the delay will be before publication as IS 29500:2008 happens, and I'll beg a copy of the final DIS 29500 before that just to make sure I don't step into some element of harmonization that is impacted by BRM-approved changes (especially the various conformance statements that are new in the final text).  Also, to make any contributions to identification of defects, it is important to reference the most-authoritative available documents.
   Here's what it looks like for intercepting DIS/IS 29500 activity:
        1. Usable final text available in May for provisional use (if it can be obtained) until official IS 29500 editions are issued
        2. Mechanism for receiving defects and related comments on IS 29500 operating in July.
        3. In September, 2008, SC 34 meets in Korea and takes next steps, with meetings every six months (figure March 2009 in Prague, September 2009 in U.S., then 2010 meetings in Sweden, then South Africa).
   Working groups that will be doing the technical work are yet to be set up and they will have their own meetings, conference calls, and mailing lists as well as ones synchronized with SC34.
   (I have a current passport with lots of room for visa stamps.  Now I just need a sponsor for expenses/subsistence and a national body to nominate me to a committee.  Hint, hint.) -- dh
  

2008-04-10 Rick Jelliffe Perspective on SC34 Activity

Rick Jelliffe has a great perspective on the just-concluded SC34 plenary meeting.  Because he wasn't there, he offers it in a "Fake blog from SC34 meeting in Norway."  Jelliffe offers up some important items to hold onto here:
        1. The main SC34 web site (hosted in Japan by the SC34 Secretariat)
        2. The page for accessing public SC34 documents (rewards exploration)
        3. A reminder that TrueType is connected with the ISO/IEC Open Type standard, maintained in SC34 (and relevant for nfoWorks) with a hidden reminder that getting Asian scripts right is probably one of the best demonstrations of harmonization going.
        4. An useful sketch of SC34's interests and responsibilities
        5. Another reminder of my own armchair critic status, something I am working to alter
        6. A discussion of the criticality of accessibility considerations and the resources that apply in the work of SC34 -- a topic that it will be essential to address with regard to harmonization
        7. An injunction to become involved and where to do that (OASIS, W3C, Ecma TC45, the national mirror of SC34 in your neighborhood, etc.)
        8. Links to the DIN NIA-34 update on the harmonization investigation (PDF file), great work that nfoWorks should align with
        9. An interesting side comment about the use of topic maps to present ODF-OOXML mappings (although DIN is focused on translations, not mappings, because of a number of issues that translation surfaces, including round-trip degradation in collaboration scenarios)
        10. Another side comment on how the concern for synchronizing ECMA versions and SC34 versions of OOXML might be extended to the case of OASIS and ODF as well.

Unburdening Overwhelm: Covey and Peace of Conscience

I'm a big fan of J.D. Meier's blog on Software Engineering, Project Management, and Effectiveness.  Meier's posts often address aspects of empowerment, development of personal effectiveness, and approaches to team effort and management.

Today's post is on the presentation of Dr. Stephen Covey at a Microsoft internal appearance.  Meier's copious notes are of the comprehensive sort that suggest the vivid reach of Covey's presentation.  I'm sure that it doesn't match being there, but there is a great deal to mull over.  I forwarded it to Vicki and she is already enthralled and passing it along to many of her contacts.

There are three small selections that I want to focus on.  I recommend the entire post.

"Beating the Big C"

Well, John Wayne didn't beat it all that well.  But this big C is about the cancerous elements that suck life and soil the soul.  Covey lists them:

• Criticizing
• Complaining
• Comparing
• Competing
• Contending
• Cynicism

Meier notices that the consequence of these behaviors and the related attitudes is that we make ourselves into victims.  We are killing our own power to contribute and make a difference in life.  It reminds me of recent events where mean-spiritedness over the OOXML standardization progress became so poisonous and debilitating to those holding Microsoft's contribution as evil.  This cynicism and the accompanying behaviors would be a great thing to give up.  I will be on guard for my own.

Communication Means Actively Listening

Encouragement of Indian Talking Stick Communication struck home.  I must listen better and that means listening until the speaker gets that they are understood.  Not necessarily agreed with, but understood.  I usually carry around a $1 coin.  I am going to remember to use one as an Indian Talking Stick:

• I'll give it to the other person first.
• They won't return it to me until they are satisfied that they have been understood.  The conversation will only be about understanding.  My job is to understand.

I may go through a few of those dollars until I become successful at hearing what others want understood.

Peace of Conscience

I don't like the introduction of "duplicity" in Covey's observation about finding peace of conscience, not merely peace of mind.  That's my signal that I need to pay attention.  I fancy the Mormon sermon's notion that an unsettled conscience is a gift.

When I lamented about "The Unbearable Overwhelm of Technical Debt," I was also facing into the consequences of procrastination and failing to keep my promises.  I didn't even carry out the task identified there until a few hours ago.  Once I began, I felt immediate relief.  The tangible reality in a simple list on a notebook page showed how much is accomplished already.  The unfinished items are simple and I have identified the steps for completing them all: there are four web-site articles to customize and clean up.  I can easily wrap up one per day without detracting from other commitments.  I now have certainty rather than a cloud of dread around what is missing and what is needed to complete the effort.

I also notice that I had restful sleep last night.  That is not ordinary these days, and I wonder if cleaning up a lack of integrity is all that it took.  My thinking is that the initial post about Dreaming in Code provided that relief.  I also took the book to bed with me, along with a pen and a stack of sticky notes, and my thoughts were on my current impressions as I drifted off.  That was different than the kind of overwhelming churning that has been more common.

Of course, as I was completing one inventory of unfinished work, I was rewarded by noticing other places where I am out of integrity.  There are two big ones hovering there in my mind's eye.  Each of them appears to be amenable to the procedure I have already identified but need to practice consistently:

1. Create a realistic inventory of the work that is required and put it in existence outside of my memory, whether in a notebook or a computer work-item document.
     
2. Find the one definite next action that, when taken, will remove the experience of overwhelm and restore my integrity.

OK, now for action, not discussion.

Dreaming in Code: The Long Tail to My Little Ecco

Me and My Ecco

It was around 1996-1997 when I was introduced to an interesting little software product named Ecco.  I am sure it was recommended to me by a coach and mentor who used it in her own work to manage commitments.  I thought I would try it.  I had no particular immediate need for the collaborative features, but old financial records reveal that I paid $52.80 to NetManage for an Ecco Pro 4.01 update on April 30, 1997.

Love the name.  This was around the time that Vicki and I had learned enough Italian to know that "ecco" is an adverb for "here" and "there" and short for "here you are."  I loved that association.  It is a great name for a digital personal-information manager.

I didn't get it.  I never did figure out how to make meaningful use of Ecco Pro.  After using it in small ways, I was flummoxed when I wanted to reorganize materials that practice taught me were not useful the way I had them.  I could never figure out when and whether material would be deleted and I was constantly puzzled by what the product actually was doing, and why.  Fundamentally, I could not discover and internalize a conceptual model by which I could safely use the thing and obtain the results I wanted.  It was very frustrating and I never got past clumsy.  (These days I have similar experience with MP3 players and how they do or do not preserve my Microsoft Media Player organizations of material and their synchronization.)

Outlook to the rescue.  Around the time that NetManage announced the cessation of Ecco Pro development, I had obtained the first public-beta release of Microsoft Outlook, starting out its life as a standalone product.  In my mind, these two events were connected.  I understood Outlook and I was much happier, enthusiastic, and rapidly switching to use it for everything I could.  It even had cross-Outlook synchronization over the Internet, although that turned out to be a serious problem with my household dial-up connection.  Later, I learned there were mysteries and incoherencies in the Outlook conceptual model too, but they were not ones that I had to confront on day one.  This has allowed Outlook to occupy the "good-enough" space in my application of it for over ten years.

I am a satisfied Outlook user.  The conceptual mysteries are ones that I can safely ignore almost all of the time.  I notice similar hiccups in my use of Windows Media Player, but they are all beyond the essentials of having it work from the beginning, and I continue to be a faithful user of WMP as well. 

I am particularly happy that Newsgator Inbox, my RSS aggregator integrates into Outlook efficiently and smoothly.  A bonus for me is that all of my Outlook content, including accumulated blog feeds, is searchable and retrievable using Microsoft Desktop Search right from my Windows XP task bar.  (My coach and her organization switched to Outlook too though I don't know if that remains the case.)  I don't think David Allen has Getting Things Done practices for Ecco Pro, although it would make sense for there to be Ecco-specific guidance.

This is not about Outlook.  I point out this experience because of an important lesson I found in the paperback edition of Dreaming in Code.  It is about the important of encouraging a successful conceptual model and about software products very often failing to be evocative for that. 

It is also the case that it is rather random who "gets it" and who doesn't, and then whether they like it or not. 

I think this is particularly important around software products that are offered as tools for productivity (and social connectivity/collaboration).   If the product is intended to be an instrument for a human activity, how it resonates with that activity is very important to pay attention to.  How it evokes populations of adopters is even more important.  That's the lesson extrapolated from my anecdotal experience, failing to wrestle Ecco to my good use while persisting with Outlook and Windows Media Player since the days of their initial introduction. 

Others will notice that their experience and perceptions of these products are different than mine.  We need to recognize that this says at least as much about us (who are the recognizers of affordances in products) as the products.  Products land differently in the intended use and conceptual grasp of different folks. 

The fortunes of software producers will hinge, of course, on how that is dealt with, along with other factors under their control, such as basic operability, coherence with a known platform, reliability, and appropriate support.

Scott Rosenberg's Long Tail Experience

I had long forgotten about my experience with Ecco.  I was startled to see it mentioned in the last pages of the paperback edition.  Rosenberg loves his Ecco.  It is his instrument for organizing and writing books.  He recounts his own use of Ecco Pro's ten-year old code and how it contrasts with Outlook for him (p. 339).  And he's clearly correct with regard to the power of Ecco as an outliner and information organizer, something I can appreciate even though I long abandoned my effort to figure it out.  (I don't read the last chapters of mysteries first, but for Dreaming I dove into the end first.)

Rosenberg looked at Chandler, the project that the Dreaming in Code story is woven around, as a potential way to replace his use of Ecco Pro before the bits rotted so much that it would no longer run on some future operating-system and hardware (p.344).  This was his personal reality test for each version of Chandler that he installed.  He was also inspired by the ease with which a long-standing Ecco feature was proposed to Chandler and added to its enhancement list (p.345).  But Rosenberg had still not adopted Chandler by the end of Summer 2007 (pbk p.360).

Ecco is Free Abandonware.  When Netmanage abandoned further development of Ecco Pro, the software was made freely-available.  It remained a closed-source, freeware offering.  It is amazing to me that there is still a community of active Ecco Pro users and enthusiasts.   Without the web and Internet, I don't think that would have happened.

Served by the Long Tail.  Ecco Pro has all of the markings of a niche product that, after 10 years without an update, remains in use among a small population of devotees.  The community size, and even its decreasing, is miniscule in proportion to the size of the overall computing population.  Whether or not there is critical mass for perpetuation of Ecco Pro, it is the long-tail visibility that allows the community to coalesce and be sustained.  That community, although working more with a freeware than open-source model, may or may not have critical mass for preservation of its existence.  There is a common feature of smaller open-source projects: Having working code that can be exercised and built upon.  There's also something about being small enough for individuals to grasp and add their contribution.  That's phenomenal in this case.

Even though the source code has never been released, there is recent revitalization of the product.  Rosenberg marvels at this phenomenon, crediting the existence of a plug-in model for Ecco Pro for its feasibility (pbk pp.360-361).  I think that long-tail supporting structures are also important, including the existence of a Yahoo! Group and other ways for enthusiasts and supporters to connect and collaborate on the perpetuation of a favorite instrument.

Recognition and Reflection

Something familiar in the mirror this way comes.  I find myself as a one-man supporter of a 10-year-old niche product myself.  I hadn't made that connection until just now.  The community is different, because the open-source software is middleware known only to administrators, integrators and developers.  And it connects mainly proprietary products.  Engagement is necessarily different with different flavors of stakeholders. 

I worry about critical mass of the community and the inevitable bit rot, something that Windows Vista and 64-bit platform developments already portend.  We have not found a forum for mutual recognition and sharing of concerns and approaches.  I wonder whether creative devotees will appear or it simply ends with me.  I need to look at what is missing in my conduct that would evoke an opportunity for participation.

The Unbearable Overwhelm of Technical Debt

I noticed that recent efforts to increase my level of organization and productivity have shown up as disorganized and unproductive.  There is also some sort of overhanging cloud of technical debt in the form of incomplete projects and activities.  On top of that, I have the definite sense that I am slowing down and that times of focused concentration are not so easily generated as in my energetic youth.

Someday has arrived.  I have a number of arrangements that were carried out at a just-good-enough level where now it seems as if all of them now have a claim on needing to be brought forward to the long-promised improved state before I built atop their foundation.  The alternative is even more technical debt, and I find that overwhelming.

The advice of past mentors and coaches comes to mind.  Two practices seem to apply here:

1. Ensure that all of the incomplete activities are written down and kept in existence outside of my head.  I can then look at them for the specific next actions that will move them along.
     
2. Find the one action that, if taken, will free me from the experience of overwhelm and provide some satisfaction and accomplishment with which to move forward.

Writing this post is not (2), so there is limited therapeutic value in writing this. 

I notice one place where I feel blocked in moving ahead without having it finally settled.  It has to do with the plumbing of my web sites.   My first reaction is fear that will be too much of a distraction from all the other activities I have simmering away.  I suppose that practice (2) would be to apply practice (1) to that area.  OK, I can go that far.

 
Comments:

 
And I think the way to make it work is if practice (1) can be done in an agile way. That is, how little can be done and what is the easiest way to do it?

I will be moving to a practice of triage, but will work to apply your practice (1) to the projects that are put away, or to sleep, or whatever state they are put in.

# posted by  wla101: 03 April, 2008 19:18

 

Post a Comment