Done is better than Perfect

Earlier in the week I attended a NodeJS meet-up at Hacker Dojo. Outside the event room was a sign “Done is better than perfect”.

In May of 2015  the Amtrak Northeast Regional train from Washington, D.C. bound for New York City derailed resulting in 8 deaths. Investigations revealed that this particular route did not have the advanced safety technology (“positive train control” (PTC)) meant to prevent high-speed derailments. Under current law, the rail industry must adopt the technology by the end of this year.

Last month, 6 Irish students died in Berkeley when a balcony collapsed. One of the surviving students will never walk again. Mayor Tom Bates said “investigators believe the wood was not sealed properly at the time of construction and was damaged by moisture as a result. He said that appears to be the prime cause of Tuesday’s tragedy.”

The story is always the same.  Investigation after a horrific accident reveals that though the service was completed (done) it was not done “right”. Good practices and established processes were not followed. Just enough was done to pass an inspection or get a permit.

The Shinkansen (A.K.A Japan’s bullet train) was introduced in 1964. Over its 50-year history, carrying nearly 10 billion passengers, and traveling at speeds ranging from 120mph to 180mph, there have been no passenger fatalities due to derailments or collisions, despite frequent earthquakes and typhoons. As a young engineer on training it was a treat for me to travel on the Shinkansen from Osaka to Tokyo. I was amazed at the smoothness of the ride and marveled at the engineering feat that made it so. The Shinkansen was not built to perfection, it was just built right!

In the case of Bookout v. Toyota, Toyota was found guilty of a UA (unattended acceleration) death. It was due to a software bug which was a result of not following the established development processes. Michael Dunn in this EDN article titled “Toyota’s killer firmware: Bad design and its consequences”  provides an exhaustive explanation of the consequences of winging it. When the feds reached a settlement of $1.2B Eric Holder, the U.S. Attorney General said “When car owners get behind the wheel, they have a right to expect that their vehicle is safe. If any part of the automobile turns out to have safety issues, the car company has a duty to be upfront about them, to fix them quickly, and to immediately tell the truth about the problem and its scope. Toyota violated that basic compact.”

This same concept applies to the software we write. When a user uses our software they have a basic expectation that it will function as promised. That it will function under load, in different network conditions and if it involves critical systems it will have built in redundancies.

In the everyday world where software apps govern our daily lives, the phrase “Done is better than Perfect” has a very simple definition. Build small, build well, ship often. “Build well” means do it right, follow good development and test processes, and aim for proper working functionality.

Dave Rooney in his post puts it well, “Done” and “perfect” refer to the scope of the functionality, not its quality.”

Mark Zuckerberg in his letter to his shareholders about the “hacker culture” before the IPO wrote: “…Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.” It was just about doing smaller iterations but every iteration done right. The iteration should work like the user expects.

Aileron in their post put it aptly,  “A corollary to “good is better than perfect” is “done is better than perfect”. This does not mean doing a mediocre job or producing a poor-quality product. Being done and finishing a task gives every business person an outcome. This result will give them important success or failure metrics to decide what their next step will be.”

Done right is better than perfect!

Advertisements

Life is what we make it

Yesterday, after a gap of about 30 years, RT called me. RT and I were classmates, pursuing an undergraduate degree in Industrial Electronics. After a few pleasantries he told me that he clearly remembered how I had helped him learn the Darlington pair.

RT suffers from Multiple sclerosis. His vision is failing rapidly and needs assistance to carry out even the most basic of tasks  we take for granted. His condition seems to worsen by the day.

About six weeks back I had the opportunity to attend a company team building exercise in Grand Lake, Colorado. A picturesque gateway to the Rocky Mountain National Park.

The walk from the hotel to the city center, about a mile was painful to say the least. A few days before the trip I had hurt my knee during a run. All through the walk the majestic rockies and the serene Grand Lake bore witness to my complaints.

Even with a limp I did get a nice lunch and sat by the lake, sipping coffee trying to exercise my knee, hoping to reduce the pain. The lake was partially frozen and the afternoon sun  glistened off its icy cover. The expanse of the quiet lake would have put anyone at ease. Not me.

The walk back was even more painful, because part of the walk was uphill. With an ice pack on my knee I sat on the couch in my hotel room blankly staring at the snow covered peaks while my face wrenched in pain.

In my self involved world that I had woven for myself I had totally forgotten that I was fortunate enough to lay at the bottom of a crucible of natural beauty which I chose to ignore.

When RT talked with me he sounded in much better spirits than I was then. He sounded happy, fulfilled and  buoyant. He was enjoying talking with me. Never in this short conversation did he hint about his illness. Something I need to heed and learn…

“Live long and prosper my friend..”

 

 

 

 

Detached…not quite!

jQuery 1.4 has a very helpful function ‘detach’ where I can detach a section and keep it away for later use. The best part is that it keeps all my bindings intact. But like anything else you need to watch out for caveats.

Consider the following example:


$(document).ready(function (){           

   //detach and keep the reference
   var $a = $('#div-abcde').detach();

   //try to change the value of one of the detached elements
   $('#abcde').val('5678');
   
   //attach it back
   $('#div-abcd').after($a);
   
   //output
   alert($('#abcde').val());
  });
<form id = "grid-3762" name = "grid" action = "">
     <div id="div-abcd"><input type="text" id="abcd" class="abcd" value="abcd" /> </div>
      <div id="div-abcde"><input type="text" id="abcde" class="abcd" value="abcde" /> </div>
</form>

This works as expected. The statement ‘$(‘#abcde’).val(‘5678′);’ has no effect as this element has been detached. So the output is as expected, that is ‘abcde’.

Now lets do the same example a little differently. Consider this:


$(document).ready(function (){           
    //keep a reference to the element.
    //remember this element wil be part of the detach
    var $r = $('#abcde');
   
   //detach and keep the reference
   var $a = $('#div-abcde').detach();

   //try to change the value using the reference
    $r.val('5678');
   
   //attach it back
   $('#div-abcd').after($a);
   
   //output
   alert($('#abcde').val());
  });

So what we are doing here that we are changing the value of the element by using a reference to the element. This is reference $r to the element.

Now the output is ‘5678’!

So even though it is detached it still maintains its references.

For everything there is a function!

JavaScript as you know is a functional language, meaning that functions are treated as ‘first class’ objects. They can be used as plain old functions, assigned to variables, passed in a parameters, created on the fly, extended and act and work as objects.

A PHP programmer who has been treating JavaScript as a supplementary language finds this variety of function construction and invocation a bit frustrating. To ease the pain here is a short essay.

There are three common ways of defining and invoking a JavaScript function.

The most common is the ‘Named function’ that we all know and love.

    //named or declarative function
    function myFn(someVar){
        alert('myFn executed - ' + someVar); 
   };
   
   //To invoke
    myFn(77);

The output is as expected: myFn executed – 77

Just to whet your appetite this simple function can have properties and methods and can be augmented using the prototype property.

The next method of declaring a function is as an expression or literal. Consider the following example:

//function expression or function literal
   var myFn2 = function(someVar){
      alert('Function executed - ' + someVar); 
   };
//to invoke
   myFn2(88);

The output in this case will be ‘Function executed – 88’

As you can see there is nothing special about this except that the variable myFn2 holds the reference to the function.

The third way of defining and invoking is using the constructor pattern.

//using the constructor
   function myFn3(someVar){
      alert('Function executed - ' + someVar); 
   };
//to invoke
   var myFnInstance = new myFn3(99);

The output in this case will be ‘Function executed – 99’

But, all said and done, these various function incarnations begs us the question…where should we be using each type, how and why?

One of my favorites is to pass a function as a parameter. This is something very powerful and its applications are only restricted by your imagination. Consider the following example:

 //Main function which accepts a function reference as an argument
   var myMainFn = function(someFunc){
      someFunc();
   };
  
   //A simple function expression
   var myFn1 = function(){
      alert('myFn1 executed');
       
   };
   
   myMainFn(myFn1);

The output is ‘myFn1 executed’!

Think about it. A main dispatch function which receives a function reference as an argument. We now have a dynamic function dispatch table.

My next favorite type is ‘Returning Functions’. Consider the following example:

//the main function
 var myReturningFn1 = function(someVar){
      alert(someVar);
      //returning function
      return function(){
         alert(++someVar);
      };
   }
   
   var returnFn = myReturningFn1(111);
   returnFn();

In this function rather than returning a variable it returns a reference to the function. In other words if I were to do this:

myReturningFn1(111);

the output would be ‘111’.

But by doing:
var returnFn = myReturningFn1(111);
we are getting a reference to the return function. And to execute all we do
returnFn() and the output would be 112.

I could have written the function like so:

 var myReturningFn1 = function(someVar){
      alert(someVar);
      
      var returnFn = function(){
         alert(++someVar);
      }; 
      return returnFn; 
   }
   
   var returnFn = myReturningFn1(111);
   returnFn();

However you must realize that the first way of writing is more in vogue.

Getting back to the first way of writing the function an astute reader will have realized that after doing:

var returnFn = myReturningFn1(111);

The function myReturningFn1 has finished and gone out of scope and so has the variable someVar! But when you now do

returnFn() it actaully increments someVar. Which means that even if the outer function has gone out of scope the inner function still has access to its variables. This is called a ‘closure’, one of the most important concepts of a functional language and a very powerful feature of JavaScript. In this case the outer function myReturnFn1 closes over the inner function resulting in a closure.

More than that, one of the most valuable qualities of the returning functions is that you on the outside do not have any access to the variables of the outer function. Only the returning or the inner function does. You may say they are private variables:-)

One typical pattern I love to use in my programs is:

var myReturningFn1 = function(someVar){
      alert(someVar);
      var someObj = {
        init: function(){
         alert('Init! - ' + ++someVar);
        } 
      };
      return someObj;
   }
   
   var returnFn = myReturningFn1(111);
   returnFn.init();

The output in this case is ‘Init! – 112’

This way I have my methods neatly tucked away and my private variable safeguarded from accidental changes.

Finally my next favorite is the ‘immediate functions’. Consider the following:

 (function myImmediateFn(){
      alert('Executed!');
   })();

The output will be ‘Executed!’

The beauty of this is that the function is declared, executed and then destroyed, all in in go. If you wanted to pass in a parameter then we could write this as:

Finally my next favorite is the ‘immediate functions’. Consider the following:

 (function myImmediateFn(someVar){
      alert('Executed! - ' + someVar);
   })(88);

The output will be ‘Executed! – 88’

This pattern is also called the (function(){})(); pattern.

This is used very often in plugins.

(function($) {
  //your plugin code
})(jQuery);

I tend to use this pattern quite a bit when I want my libraries to be initialized on load.

I hope this essay has created an appetite for more functional exploration.

If you plan to go ahead I must recommend these three books by JavaScript gurus!

1. Secrets of the JavaScript Ninja – John Resig
2. JavaScript Patterns – Stoyan Stefanov
3. JavaScript: The Good Parts – Douglas Crockford