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

   530,000,000      The Cambrian explosion

       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.

Rx for a Team Culture

Do you think you need a prescription to create a Team Culture - OK - here you go.

1. Executive-level statements in public and private about the importance of team players (not just teamwork platitudes).
2. Executives model team player behaviors (not just preach behaviors).
3. Promote and reward people with team player skills, publicly announce reasons including team player factors for decision.
4. Reward team players with important assignments.
5. Adjust individual performance appraisal systems to include specific team player behaviors.
6. Hold training on attitudes, skills and behaviors of team players.
7. Reward team players with higher salary increases, and tell them why.
8. Create an incentive system that rewards team effort (not individual effort).
9. Institute flexible compensation programs that allow managers to pay individuals that contribute to the team culture.
10. Include team-player skills & abilities in management assessment programs.
11. Develop programs of team awards that motivate the teams, flexible enough to tailor it to team needs.
12. Appeal to intrinsic motivation, encourage managers to use nonmonetary forms of reward.
13. Eliminate competitive rating and ranking appraisals programs.

- From Glenn M. Parker's - Team Players and Teamwork (1996) pp. 146-147. New hardcover edition via Amazon.