The Chainstore Paradox, Blink, and Think

As I was reading up on the Chainstore Paradox I came across an interesting point on the economy of decision effort which classified decision making effort into 3 levels

  1. Routine
  2. Imagination
  3. Reasoning

At the Routine level decision making is requires little effort as decisions are typically arrived at by default in this situation. At the Imagination level the decision making requires more effort and the ability to see oneself in the opponents position, it is here that the majority of decision making in business is made due to the additional costs of moving to the next level of decision making, Reasoning. Interestingly moving from the imagination level to the reasoning level may not yield better results, especially if the computational complexity introduced is prone to error or bias.

Determining at what level to make a decision is a real skill. I have read a couple of contrasting books on this subject, Blink by Malcolm Gladwell and Think by Michael LeGault. It is the decision, whether to approach a decision with the intuitive thinking promoted by Gladwell or the critical thinking promoted by LeGault, that is of interest to me. In the end I guess it comes down to situational factors, what is the timeframe for the decision, the relative costs, and ability to change a decision when more information is known.

On Interviewing

“If you believe that pleasant interviewing skills, a good handshake or the right outfit are a better predictor of future performance than what the person has actually shipped in the past, I think it’s worth pointing out that you’re nuts.” – Seth Godin

Well interview season is coming up for me as I look for an internship this summer. One thing I’ve learnt from my HR class last semester was that behavioral interviews were one of the most accurate way of assessing future performance. So I’ve been busy practicing to be a good interviewee, it’s a different mindset than I had approaching it from the other side of the table as a hiring manager!

Random π

The ridiculous fish blog recently posted an entry about using “random” large integers to calculate π. That post was in the context of getting blog commentators to enter two large integer values as a kind of CAPTCHA to keep out spammers automated commenting bots. The idea of calculating pi using just random sequences of integers was intriguing to me so I set about implementing it in JavaScript. I’ve included the functions used below:

First a fairly simple function that returns a random positive integer:

function randomPositiveInteger()
   return Math.round(Math.random() * (Math.pow(2, 31)-1));

Next a JavaScript implementation of the binary greatest common denominator algorithm followed by a simple coprime function that takes two positive integers and determines if they are coprime or not (by determining if the gcd is 1):

function gcd(u, v)
   var k = 0;
   while ((u & 1) == 0  &&  (v & 1) == 0)
      u >>= 1;
      v >>= 1;
      if ((u & 1) == 0)
         u >>= 1;
      else if ((v & 1) == 0)
         v >>= 1;
      else if (u >= v)
         u = (u-v) >> 1;
         v = (v-u) >> 1;
   } while (u > 0);
   return v << k;

function isCoprime(a, b)
   return gcd(a,b) == 1;

Finally the function that ties it all together; Note the assignment of properties to the function object so that the function can maintain a history of results without having to store variables outside its scope:

function nextPiEstimate()
   /* Initialise the properties used to hold the tallies if required. */
   if (nextPiEstimate.totalCoprimePairs == null)
      nextPiEstimate.totalCoprimePairs = 0;
   if (nextPiEstimate.totalPairs == null)
      nextPiEstimate.totalPairs = 0;

   /* Generate two random integers */
   var a = randomPositiveInteger();
   var b = randomPositiveInteger();

   /* Determine if we are dealing with a coprime pair or not */
   if (isCoprime(a,b))

   /* Determine the percentage of pairs that were prime and calculate Pi */
   var invertedPercentage = nextPiEstimate.totalPairs / nextPiEstimate.totalCoprimePairs;
   var pi = Math.sqrt(invertedPercentage * 6);

   return pi

See the code in action

JavaScript & Java; Object-Orientated vs. Class-Orientated

A software developer can sometimes choose the language they use to program with, but often the decision is already made. When developing software using a language a developer is not familiar with they can go one of two ways, either learn the new language with its accompanying paradigms and idioms or seek to leverage their current programming style into the new language.

In many cases the transition between them is not especially difficult, Java and C# are reasonably close cousins for example, and a competent programmer can switch between them without much cognitive dissonance. Sometimes the distance between the two paradigms is substantial.

When I think of the conceptual differences between languages I am often reminded of Java and JavaScript (recently christened the “worst invention ever“). Owing to its name and curly braces style JavaScript is often though of as very similar to Java, at least by people who’ve never programmed seriously with it. When these developers do begin using JavaScript for serious work they soon stumble into the differences. We then come back to the learn or adapt choice.

“Leveraging their current programming style”, the word “Leveraging” comes from the word “Lever” which can be described as a bar or rod used in combination with a pivot point to transmit force. The goal of a software development is what’s at the other end of the lever. How we choose to apply the force, or our time and mental energy, to reach out goals is my area of interest. Leveraging our existing knowledge to achieve our goals is often a good idea, we learn a lot on the way to becoming the kind of developers we are after all. Discarding that and starting from scratch on each development is not a pragmatic approach. Another aspect of pragmatism however is recognising when our existing experience and skills are not currently a good match for the current problem domain. When our skills are a bad fit we can go through a lot of motion to “force” the fit. An example of this is when people try to make JavaScript into a class orientated programming language (aka a conventional OO language).

Coming from a background in Java, I’ve spent many hours trying to figure out how to make JavaScript objects act more like Java objects in every way. – Nicholas C. Zakas

Should we really be spending many hours trying to work against a language? While I am sure Nicholas is an accomplished developer I don’t believe his approach to JavaScript is the most effective. Concentrating your efforts on overcoming the perceived weaknesses of a language by coercing it to act like another language is not a productive use of time. Seeking to more fully understand that language and its underlying paradigms is a more productive use.

“Embracing the new style”, this alternate approach is also about leverage, however what we are leveraging here is not our current capabilities, but our capacity to improve our current capabilities. As well as the goal of achieving our development target we should also be focused on achieving our longer term targets. One of my longer term targets is to improve my software development skills. One way to do this is to continually improve our current knowledge, reinforce it with experience and expand it with learning and experimentation.

Knowing other systems and paradigms expands the world inside your brain. – Yukihiro Matsumoto.

As with all decisions we make there are tradeoffs, when considering the lever we choose to apply we need to weigh up the effort required to achieve the desired result. Remember there are always external constraints, such as deadlines for example! Remember though that the greater up front effort often has a better payoff in the end. In Steven R Covey speak “Sharpening the Saw” may have more overhead initially but subsequent productivity is increased. As far as JavaScript is concerned cast off any misplaced prejudices and come toappreciate that most misunderstood of languages called JavaScript, be prepared for an interesting world of closures and prototypical objects, and oh yeah you can use a string in a switch statement!

Some related reading:

  1. Emphasising the Role of the “Object” in Object Orientated Design.
  2. Evolution of a Haskell Programmer

Launched a new link blog

After a lapse in writing (due to my failure to roll my own blogging engine in my spare time) I’ve given in and started to use blogger as a link blog. This site will remain the source of my longer musings while my new site, Ben Meadowcroft, Link Blog, will contain all the interesting links I’ve wanted to blog about but never had the time to manually add.

The new blog comes with a ready made atom syndication feed so feel free to subscribe to that (I currently recommend SharpReader as my feed reader).

New release of my popular CSS templates

The most consistently popular section of my site is the CSS templates [zip file] that I provide, as such I have spent a bit of time on the templates and given them an overhaul. There is some nice use of semi-transparent backgrounds and user scalable font-sizing on show (using the browsers own controls!).

screenshot of one of the templates

The CSS template is now licensed under a creative commons license specifically the Attribution-NonCommercial-ShareAlike license. Only the templates (HTML, CSS and graphics) have been licensed under this creative commons license, the rest of the content of this site remains under my copyright. Note that for the attribution purposes of the license retaining a comment in the source code is sufficient attribution. If you distribute the graphics desperately then please attribute them appropriately.

If you have any comments on the templates, or wish to license them for commercial use, please contact me.

A cautionary tale of the perils of procrastination and blogging

Blogging has become something of a lower priority for me at the moment, nevertheless I still intend to keep going with it, the biggest barrier to my success revolves around my having a bad case of the NIH syndrome, coupled with the need to satisfy a somewhat mammoth personal wish list when it comes to creating my own personal blogging software.

I could have settled with moveable type or similar, but I just can’t bring myself to do it. Professionally I have developed a number of content publishing sites, as well as a variety of highly complex “web apps“, so technical skill isn’t the problem. (I could use PHP, ASP, ASP.Net, JSP…) Unfortunately I am not under any time constraints when it comes to developing this site, I can work with my prototypes and Visio diagrams to my hearts content, always getting closer to that final result with every attempt. When I program professionally I always have deadlines and clients to satisfy, plus I get paid for it!

Anyway for anyone considering starting a blog, use something automated, there are plenty of tools out there. I don’t have any particular recommendations for blogging tools, doing it regularly by hand is time consuming, error prone and did I say time consuming? (and when you’ve left university to start a full-time job, gotten married, and started house hunting you’ll notice the lack of time a lot more than when you were a single student!).

Anyway I’m going to move this site over to one of my prototypes systems in the new year, honest, and develop it in an evolutionary process rather than the current feature creep prone waterfall model. Now if I could just add the atom api to it…

Some Diversions

Some interesting links I’ve come a cross recently (via a variety of people’s sites I can’t remember, checkout my blog roll): Avoiding the Santa Claus approach to content management (A valuable wake up call for me), Examining differences between dynamic and batch publishing and finally the eXtremely Simple Database.

Emphasising the Role of the “Object” in Object Orientated Design

This is just a short pointer to an article written by James O. Coplien who happens to be a visiting professor at my old University. The article is entitled “Teaching OO: Putting the Object back into OOD“. Anyway the central premise of the article is that objects themselves should be viewed as the fundamental building block of object orientation rather than the class.

The article also reminded me of how objects are developed in JavaScript, object prototypes are used in the absence of the class found in conventional OO languages. While I certainly haven’t thought about consigning classes to the scrap heap (the article doesn’t go down that route either) it certainly made me think about how dynamically adding properties and methods onto objects can be a useful tool without having to explicitly do the work of defining a class that implements that functionality. Shifting your thoughts from the design of the hierarchical class structure to the design of object functionality and interface based object roles may help you to appreciate object orientation and it’s flexibility a little more.