Bashing the iPad - but will you purchase?

The question is not will the iPad do everything you or I wish it to, clearly Apple did not intend it to be the One Device to Rule Them All.  Apple's intent has been clear for several years.  Jobs stated the intent in a speech 9 years ago: The digital hub strategy.



To see the ecosystem of the computer as a hub of your digital life.  They have executed on that vision with the iPod, then the iTunes store, the iPhone and the App store, now the iPad and the iBookStore.  Are we following a pattern, is there a cookbook?  The leader has a vision, shares the vision with the followers, the followers buy into the vision and together make it a reality.  

The new product adoptions phases are progressing quite nicely.  Apple is a master at this process, described by David Pogue in:
http://pogue.blogs.nytimes.com/2010/01/27/the-apple-ipad-first-impressions/.

Wildly Successful New Product Launch Phases
Phase 1 feverish speculation and hype (preannouncment)
Phase 2 disappointment and bashing (prerelease)
Phase 3 attainment anticipation and adoration (post release)

So we are clearly in Phase 2 (bashing).  With rational reasons, but when Phase 3 (attainment) arrives - will you rationalize these arguments and purchase an iPad? I've got $5 on Yes, you buy.  Actually a bit more than $5 as I purchased Apple shares just under $200 after the bounce and drop on the iPad news.

My reasons for the confidence in Apple:  They have executed on Jobs vision, they are in iteration 3 of new products that connect to the computer hub.  I have Pogue's model of phases of product adoption for an explanation of the media. I refer you to the long list of "desired" feature missing in the iPhone, and the large number of iPhone sells.

Apple has the magic balancing act of the perfect engineer - they are at the top of the game in the compromise to optimize simplicity thereby maximizing enjoyment of the product.  They are not as concerned about shareholder value as they are customer satisfaction.  They have a very good measure of customer satisfaction.  I think they are getting the customer satisfaction equation optimized.

Visible Progress the Best Motivator

Scrum uses a burn down graph to track progress. Turns out this is a powerful motivator.

An article in Harvard Business Review discusses a survey of 600 managers on motivation in the workplace.  The number one from manager's perception is recognition for good work.  However a multi-year study tracking workers has a very different finding.  Contrary to manager's belief workers define that progress is the top motivator.

"On days when workers have the sense they're making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak."

Note the removal of impediments in the quote above.

The article supports the Scrum practices of tracking progress every day, of removing impediments, and of celebration of progress toward the companies goals.

An interesting TED video is Dan Pink's talk 'The surprising science of motivation'.  Where he also describes how our common understanding of motivation via rewards is contradicted by the science on motivation.

Relearning to Count - Zero, One, Many

I have been thinking about the methods we use to count with.  What method of counting is most appropriate to the task at hand (pardon the pun).  A smart friend of mine told me that developers need to relearn to count.  As a software developer the appropriate method of counting is, zero, one, many.

The first time we learn to count we use our fingers in the simplest technique.  Some time early in childhood we learn to show fingers for our age, "I'm this many (shows two fingers)".  Then we actually learn to count, 1, 2, 3.  Later taking it up to 10.  So a base-10 number system seems like a natural human number system.  But is this true?

I've been wondering why we used a sexagesimal number system (base-60) for time.  A hour has 60 minutes and 60 seconds in the minute.  Why use this system when it would appear a base-10 system would have been more natural?

These two facts perplexed me.  We learn to count in base-10, yet our fundamental unit of measure is base-60.  Reading about the Babylonian number system may lead to a plausible explanation.  We adopted the Babylonian system for time.  And perhaps the Babylonian children learned a different method of counting, not counting fingers - but instead counting finger joints.  If one counts all the finger joints on the fingers one can count to 12 just using the four fingers.  That is much more efficient.  So using the left hand to count in base-12 and the right hand to count the multiples of 12 one arrives at a combined base-60 system of counting.  A bit more complex than counting to 10 on the fingers.  But the Babylonian's were not children. 

Compare the simplicity of a base-60 system to a base-10 system when one is in a shop counting baskets of grain.  There is a high chance that there will be more than 10 baskets, but lower chance that there will be over 60 baskets before someone wants to start marking on clay tablets.  Perhaps the shop keepers relearned to count in base-60 because it afforded fewer trips to the clay tablet.

For non-developers you may continue to think in base-10. As a software developer you need a slightly more abstract system.  That system is Zero, One, Many.  Simple.  All you need.  Zero is used to mean the empty set, nothingness, the absence of quantity.  Zero has an interesting history.  One is used to mean the unique thing, unity, not Zero and not Many.  Many is used to mean a collection of like things.  Modern programming languages have allowed this abstraction level with many types of objects to represent Many.  We have Collections frameworks all designed to represent a specific constraints on Many, but the abstract concept is still Many.

Is there an anatomical representation of this system (Zero, One, Many)?  How about the closed fist for Zero, the raised index finger for One, and the open palm held horizontally ready to hold the collection for Many.

(NOT) Reliable and Valid Research - Fox News

Fox News quotes poll to show that perhaps scientist falsified research to support global warming.

Rasmussen Poll:  Did scientists falsify research to support their own theories on Global Warming?
59% Somewhat likely
35% Very likely
26% Not very likely
-----
120% total people responding

Well that is a poll that you can take to the bank.

Perfection and constant change

"To improve is to change; to be perfect is to change often."
      - Winston Churchill 

The Universe - by the numbers

The Universe appears to be quite old but for some reason the really interesting things happened at either end of the arrow of time.  Being a fan of This Is Indexed I though I would try one myself - nope not funny.

Everything interesting happens at the ends of time.

      Age (years)

13,700,000,000     Universe

 4,600,000,000      Solar system

 4,570,000,000      Sun

 4,540,000,000      Earth

       2,500,000      Stone Age (begins)

           15,000       Domestication of dog, cow, pig, etc.

           10,000       Argicultural revelotion

             5,300       Bronze Age (begins)

                230       Industrial Revolution (begins)

                 47       me

ToDo or Not ToDo - that is the question.

What does a TODO tag in your code say about you as a developer?

When is a TODO not appropriate - is it every appropriate to postpone work that you recognize, but just don't want to deal with now?  Is procrastination a trait that we encourage or discourage?

I posit that quality code has very few if any TODO tags.  That there is a inverse correlation between the percentage of TODOs in a code base and the quality of the code.

Srikaran Reddy had this argument to make:

TODOs present in code may be indicative of the quintessential engineer: one who can distinguish between what is required at the moment versus an ideal, or potential future requirement, that is of relatively lower priority. The term 'sine qua non' comes to mind. This is especially true when maintaining inherited code. On the other hand, a TODO could represent some sloppiness. There are different flavors of TODOs that need to be factored into this argument.

The good thing about TODOs is that they are easily tracked, and after a simple search, could be transformed into whatever ticketing or bug/issue tracking mechanism the team is using.

One might argue that a TODO is simply an item in your uncommitted backlog that happens to be noted in your code.

Srikaran may be the quintessential engineer, so I respect his point.  Are there flavors of TODOs just like there are flavors of quarks?  Yes I think there may be, but how do we tell them apart?  Let's put a flavor tag and annotation after the TODO comment.

Here's an idea - allow the IDE to grow the icon/font associated with a TODO by the interest rate for the technical debt it represents (I suggest prime rate + 10%).  Therefore after several years of a legacy TODO the icon or font would be 3X the normal code text.

TODOs in code do provide an easily searchable tag, it is a nice and neat way to decorate the code with more work to be done.  In the case of the bug tracking system the TODO represents work needing to be done in two places - the code base, and the entry in the bug tracking system - neither of which were done by the addition of the TODO.

The argument for a TODO representing a backlog item is weak, but interesting rationalization.  I think the purpose of the backlog in Scrum is to be a visible prioritize list of work.  The TODO fails on both attributes of this list type.  It is not visible to everyone on the team, especially the Product Owner who is responsible for prioritization.