Unanswered Questions

In my experience, programmers vary in their ability to tolerate ambiguity, or in their ability to proceed without an answer to a critical question.

For myself, I've had the sense that I have advanced in my ability to tolerate not knowing the answer to an important question.  However, it's only because of some coping mechanisms I've built up over time.  And without those coping mechanisms, I still basically stink at dealing with ambiguity at a core human level.

There is a sequence that I go through all the time:

1. No explanation yet
2. What is the real question?
3. How to file open questions while I'm working to find the real question?
4. What is the TTL on open questions?
5. How do I review open questions?
6. How do I forget to revisit something important?

And I always feel uneasy when it gets to #4-#6.  I realize that GTD is all about managing a fixed-size attention span, and keeping track of things that fall outside that attention span.  However, I stink at the paperwork part of GTD, but I try to apply some of the principles in the context of open questions.

Here is a list of ideas that relate to each other and are related to this overall theme:

• Ambiguous results
• Anomalous results
• Open question
• Loss reflex
• Disorientation cost
• Orientation rate
• Orientation ability
• Orientation cost
• Learning pipeline
• Fixed buffer size of open questions
• Open question LRU/LN cache eviction (least recently used, least needed)
• Isolating open questions in code

Here are some articles that relate to this theme:

• http://dailykibitz.blogspot.com/2007/04/tolerance-of-ambiguity.html
• http://www.cs.virginia.edu/~robins/YouAndYourResearch.html (search: "that trait is ambiguity")
• http://www.edcbmj.ir/browse.php?a_id=286&sid=1&slc_lang=en
• PragProg: Good Enough Software
• PragProg: Not Until You Are Ready
• PragProg: The Specification Trap
• PragThinkLearn: Embed Failing in Practice (p. 189)
• PragThinkLearn: Create an Exploratory Environment

This post is totally alpha and I don't even know where to go with it, but I wanted to get it out there to think about it some more, since I always think better after pressing "Post" than before.

Wish TwitterFeed supported auto-hashtags

After using TwitterFeed for a while, it's really cool!  Props to betaworks for an awesome tool!

All I want now is auto-hashtag support.

Just look for the last line of a post that is only hashtags, and #dont #take #arbitrary hashtags from the #body of the #post.

Don't bother with trying to convert blog post tags into hashtags -- I want a different vocabulary of hashtags on twitter vs. tags on my blog.

#twfeed #hashtags

Missed Tweets Through News.me

I've never really been a twitter nut.  There are already enough sources of distraction for me, I don't need to add another source.  It just seemed really noisy.

However, people have been saying and linking to important things on twitter for a while now.  I'm just not discerning enough and don't have enough time to filter the firehose in a useful way.

The most helpful summary of interesting news I skim regularly is the weekly LinkedIn emails.  In fact, I think it may have been through a link chain from one of those emails that I stumbled on unionfs, as reported in the last post.  If I could have the same thing for twitter, but personalized to the people I follow, that would be really helpful!

Ironically, as part of the effort to make this blog more stuble-upon-able, I was looking for a way to auto-post on twitter and facebook whenever I post on this blog, and I found twitterfeed.com, which does all of that and more.  And it's easy to set up.

After setting that up this morning, I wondered: "What is the company behind twitterfeed.com?", and found betaworks.  They run some very interesting sites/companies, some of which I knew about (bit.ly), some of which were new to me (findings.com, chartbeat.com).  The interesting one for me right now was another site called news.me.

Turns out that news.me is just the kind of thing that has the chance of making twitter useful to me.  If things go well, you'll probably hear more about it.

Tracking work to be done

My team had the task of porting code off of an old API onto a new (hopefully-mostly-equivalent) API.

Diomidis Spinellis wrote an article in IEEE Software titled "Start with the Most Difficult Part" (on his blog here, official reference here). Now seemed like a good time to apply the advice.

So I wanted to measure: What was the most difficult part. I wanted to know how many usages of the old API were present and where I should focus my efforts first.

So I wrote macker rules to detect usages to port. And I wrote a ruby script that drove the ant macker target and pulled the usage counts into a list of counts. Then I published the current counts and started a graph so we could get the usages to zero.

Here is the chart we ended up with:


This drove us to two useful behaviors:

1. Getting our tests converted first, the most complex one first (exposed a lot of issues early).
2. Giving our work a metrics-driven feel -- all we have to focus on is getting this to zero.

There were also two things I missed:

1. The hardest task to port was one in which the new API didn't have anything near what we needed, and the usage measurement didn't catch that. ==> A quick pass over the tasks looking for especially risky ones (where the port would be really hard) would have exposed that earlier.
2. Another team was doing other work that intersected with ours, and we were unaware of the impact of their efforts on what we were doing. ==> Being able to get their changes quickly and easily may have helped expose the problem earlier.
   

Now that we've started using git, I'm going to suggest that we do two things:

• Get an SVN task branch so we can integrate as a team during the sprint
  
• Get an SVN task branch right before merging to release and re-apply all our git patches onto that task branch so the merge is really smooth

Or maybe if we can get done in time, we could volunteer to do that for the team that has the sprint-long task (getting them on everyone else's changes with a minimum of svnmerge.py headache).