Monday, June 24, 2013

Career Survival: Honesty and Credibility

There are a lot of things that affect the success of your career, but few things affect it as much as credibility -- and there are few things that affect our credibility as much as our ability to be honest. Of course, there are other things that affect credibility -- skill and aptitude among them -- but our ability to be forthright ranks high.

Honesty in a workplace takes many forms, but it begins with being honest with ourselves. That is a surprisingly difficult thing to do in the workplace, because sometimes we know telling the truth may make things better for the company while making things worse for us individually.

I remember a time when I was quite young and I held my first non-burger-flipping job. There was an event that occurred that, frankly, I find quite embarrassing when I look back on it.  The company I was working for had decided to create a business-casual dress standard and I was ready to get out my pitchfork and torch and join the rebellion when someone suggested, "If they want us to dress business casual they should pay us extra to buy the clothes."

I can't believe, now, that I took that comment seriously then.  The truth of the matter was I was being paid to do a job, and it really is a privilege to have a job.  It is the company's right to make changes they feel is in the best interest of the development of the company.  But that isn't really even the main point.

The truth is, the passion behind the argument, "If they want us to dress business casual they should pay us extra" was never really about the money.  I think those of us involved, with a little honesty, would have admitted that it was really about the fact that we liked wearing Levis and shorts and, odd as it seems now, we were irritated that they would require us to do otherwise.  And I think this is often where the root of honesty in the workplace (and probably elsewhere) lies; it lies in our ability to objectively evaluate why we feel the way we do about things and to admit to ourselves that the truth may stand contrary to what we personally desire.

Thankfully, I wasn't foolish enough to actually voice my disgruntled concern to my manager.  Had I done that, my credibility would have taken a serious hit and I suspect my future opportunities with the company (I eventually became a software developer for them) would have also been in jeopardy.

But since then I have noticed that decisions like these are constantly before us (often they are not as silly or as obvious as this example).  My experience has taught me that the ability to see a situation from both points of view (mine and my employer's) and evaluate decisions honestly, pays big dividends with respect to credibility.  When our employer sees that we are willing to accept a tough decision that may conflict with some personal desire or goal on the basis that it is better for the company, our credibility stock increases dramatically.

Of course there is a fine line between seeing things from the company's perspective and becoming a yes-man.  Being a yes-man is as dishonest as hiding the truth for our own benefit - in fact, it is often exactly the same thing with different consequences.  Saying yes, when you know the answer should be no, just because you know it will please your boss is still lying at the company's expense for your own benefit.  This leads to another important point with regard to credibility.

In The Clean Coder, Bob Martin states,  "Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done."  It is true that a good manager will respect you when you stand on principle and help him/her to see things more clearly.  As developers, this often becomes an issue when we are asked to get something done in a time frame that we know is unrealistic, but it is also true with respect to what we develop, not just how long we take.

Of course, being honest with ourselves is also at the root of being able to be honest with when we say "no".  We need to evaluate if we are saying "no" for personal benefit or because it is truly what is right professionally.

As we learn to recognize the true reasons behind our thoughts and emotions it will help us to be more honest with ourselves.  When we are more honest with ourselves we can be more honest with our employer.  Over time, our employers will recognize that, above all, we are trustworthy.  They will realize that, when they come to us with questions or suggestions,  we will understand where they are coming from and they will know that they won't be surprised down the road because we did what they said when we should have pushed back.  In the end, this is the credibility we need to be successful.

Monday, April 8, 2013

Agile Today

In February of 2001, seventeen people gathered at Utah's Snowbird lodge to discuss software. They were a diverse group, some with competing interests, some of whom admitted that it seemed unlikely that they would "ever agree on anything substantive." While many of the concepts that emerged as the Agile Manifesto were not new concepts to those who attended the gathering, the distillation of the ideas into something substantive that was valued by them all was monumental and has become a beacon of shared values that have started to transform our industry.

The concept of Agile has been disruptive to the industry -- and that's a good thing. Many of you have probably noticed that not everyone welcomes Agile. My experience has been that interest often begins at the developer level (or even developer management level). And then acceptance of the idea is mixed from there. Of course, acceptance among the development team can also be mixed depending on the chosen methodology and how well it blends with the members of the team. It seems that Agile is most effective when the company management finds value in it and drives Agile adoption and embraces the culture change that brings to the company.

I think one thing that sometimes stands as a roadblock to company-wide Agile adoption is that there are people at all levels in a company that are largely driven by a fixed mindset. The concept I am referring to comes from Carol Dweck's book Mindset: The New Psychology of Success which contrasts a fixed mindset vs. a growth mindset. Those with a predominantly fixed mindset fear change because they fear their ability to adapt to and handle new challenges. I really like this diagram I stumbled across that explains some of the concepts of these mindsets (but doesn't replace reading the book). I do think that this plays a significant role in Agile adoption (or the lack of it).

But when it comes to Agile adoption, I love where we are today compared to just 5 years ago. I recently overheard someone say that pretty much everyone is doing agile now, and while I feel that is a gross overstatement, I love that it is even possible for someone to come to that conclusion -- 5 years ago a lot of people hadn't really even heard of it. I was hoping to find an independent source showing agile adoption percentage, but when I went looking I mostly found surveys performed by software companies and they reported the percentage of companies "using agile" ranging between 50% and 84% and I wasn't satisfied that the companies went to great length to ensure random sampling. I do presume, however, that the results at least show a ballpark of where agile is today, and it doesn't feel inconsistent with what I've experienced. More often than not, when I see job postings now, they reference Agile in one way or another.

Of course "using Agile" is a very loose term. Some people may consider themselves agile if they have a daily stand-up meeting. While a daily stand-up meeting, or more to the point, valuing individuals and interactions over processes and tools is important in all agile implementations, it alone is typically not enough to make a significant difference -- even if it's an important step in the right direction. So while measuring Agile adoption may be challenging, I did hear something recently that I found encouraging.

I was lucky enough to be at the Salt Lake Agile Roundtable meeting this month when Alistair Cockburn (the founder of this meetup), Ward Cunningham, and Jeff Patton all decided to join us. Alistair and Ward were both part of that original group that formed the Agile Manifesto in 2001. It was great to listen to some of their stories about that meeting and to hear their thoughts on Agile today. One of the things that really stood out to me with respect to where Agile is today, was when Ward Cunningham responded to a question about what has happened with the Agile movement since 2001. He said, and I'm paraphrasing, that "it is great to see other industries wanting to imitate the success in the software industry." I think that is a great indicator of how disruptive Agile has been to processes (specifically waterfall) that previously had caused our industry to be shunned and frowned upon by business and other industries. The Software industry is beginning to shed its long-held image as anti-social, difficult, and rigid; and that image is being replaced with one that is worthy of being emulated for it's ability to handle complex business requirements and respond to the ever-changing landscape of business needs. This is largely due to the values distilled by that group of individuals and published as the Agile Manifesto.

What have you seen in your experiences with Agile? Do you see Agile bringing transformitive change to the industry or do you feel that is overstated? Feel free to share your experiences and thoughts in the comments below.

Friday, March 15, 2013

Understanding JavaScript Objects

Sometimes I think JavaScript is a very misunderstood language. I think this stems from the fact that a lot of people (myself included) started using JavaScript as a means to complete quick and dirty tasks in browsers. As the web underwent transformations (remember “Web 2.0″?), the demand for richer, more interactive, client-side scripting increased. As that demand increased, a lot of us continued using JavaScript without really understanding the language (again, I’m guilty). I’ve learned a lot since then, in large part from working with Joe Eames (@josepheames) on our Html5 player, which we set out to do in a much more methodical and maintainable way. I learned a lot about JavaScript objects during that project thanks to Joe’s expertise.

You might wonder, why do I need objects in JavaScript? Well, for the exact same reason you need them in other OO languages. They weren’t so necessary back in the day when JavaScript consisted primarily of small snippits or functions to handle simple things like onclick events. But, now that client-side JavaScript is evolving more and more into mini-applications (or not so mini in a lot of cases) it is becoming increasingly important that we structure that code in a well-encapsulated, cohesive way enabling us to write SOLID and maintainable JavaScript code. If you are writing more than just a few lines of JavaScript code and are not creating objects to encapsulate and separate responsibilities, understanding and using objects may help you write cleaner code.

So, what is a JavaScript object?
First of all it’s helpful to know that JavaScript objects can behave much like an associative array or a set of key/value pairs (like a dictionary, map, or hash in other languages). For each pair, the key is the property/method name and the value is the property value or method definition. So, it’s not surprising to see that, given an object called myCat, you can create properties on it in a way that looks very much like a dictionary or map, like this:
    myCat["name"] = "Fluffy";
    myCat["color"] = "White";
That syntax, by the way, is functionally equivalent to this syntax:
    myCat.name = "Fluffy";
    myCat.color = "White";

Why the difference?
Good question. Really, there is rarely a need to do it using the dictionary-type syntax; but that way does allow you to create property names that do not adhere to JavaScript identifier naming restrictions. For example, I could create a property like this myCat["fur color"] even though “fur color” has a space in it. I cannot do that in the second example. This may be helpful in rare occasions where you may be creating objects out of data you don’t control (like a json data source, for example). But keep in mind, if you create them like that, you must also consume them like that (var color = myCat["fur color"]); Generally it’s a good idea to steer away from non-identifier friendly property names. It’s also much nicer to be able to use the more simple syntax above.

Wait a second, where did myCat come from anyhow?
The object myCat would have had to have been created prior to executing the statements above or you’d get an error indicating that myCat is undefined (which happens to be true, since I’m currently catless). So lets look at some ways to do that. The easiest way to create an object is like this:
    var myCat = {};
That creates a new object with no properties or methods. Ok, so that’s not technically true. It would be more accurate to say it doesn’t have any of it’s own properties or methods. That object does have some inherited methods since almost all objects eventually inherit from Object in JavaScript and so they inherit its methods.

Lets look at some other ways to create an object, and this time I’ll create some properties while I’m at it:
Example A
    var myCat = {name: "Fluffy", color: "White"};
Example B
    var myCat = Object.create(new Object());
    myCat.name = "Fluffy";
    myCat.color = "White";
Example C
    function Cat(name, color) {
        this.name = name;
        this.color = color;
    }
    var myCat = new Cat("Fluffy", "White");
All of these create an object with two properties (name and color) with their values set to “White” and “Fluffy”, respectively. So, why would you ever use Examples B and C if you can do this just as easily with the syntax in Example A? Well, if all you need is a cat with a name and a color, then there is no reason to use the other examples. In fact, I almost never use the syntax in Example B. But what if you want to be able to create multiple instances of an object that have the same shape and have some common properties initialized to the same values? That is where Example C comes in. The Cat function can be used to create multiple instances of a cat.

Why is Cat a function, shouldn’t it be a class?
That is a question OO programmers learning JavaScript have been asking for ages. JavaScript doesn’t have actual classes (although like it or not, it is about to). Rather than provide classes, JavaScript uses constructor functions and uses the new keyword to create instances of the type defined by the constructor (and it’s prototype). The Cat function is a constructor function. A constructor function, combined with the new keyword on the last line of that example, work together to create new objects in much in the same way classes do in other OO languages.

Prototype, what is that? And I still don’t see why I’d use Example C!
In the above paragraph, I stated that JavaScript uses constructor functions with the new keyword to create objects defined by the constructor (and it’s prototype). But I have yet to show you how to use the prototype of a constructor function — and for that reason, our examples have not been very interesting (why use Example C when you could use Example A).

Let's expand Example C some:
    function Cat(name, color) {
        this.name = name;
        this.color = color;
    }

    Cat.prototype.age = 0;

    var myCat1 = new Cat("Fluffy", "White");
    var myCat2 = new Cat("Scratchy", "Black");
Now both cats 1 and 2 have different names and colors, but they are both age 0. Of course, I can now change each of their ages individually, but it’s nice that I can already count on the fact that that property is there and initialized to 0. That prototype is used to define members that will be inherited by objects created by the Cat constructor function. Don’t worry too much about the details of prototypes for the sake of this post. I will be submitting a follow-up post to this one that covers prototypes much more in depth.

One subtle thing to take note of where JavaScript varies from other OO languages is in the inheritance of property values. If I were to set Cat.prototype.age = 3 in the example above, every cat created from the Cat function would have a default age of 3. This is a departure from what you may be used to with traditional properties in other languages.

Let’s make this example even more interesting by exploring how we would add a method to the Cat function:
    function Cat(name, color) {
        this.name = name;
        this.color = color;
    }

    Cat.prototype.age = 0;
    Cat.prototype.speak = function() {
        alert('meow');
    }

    var myCat1 = new Cat("Fluffy", "White");
    var myCat2 = new Cat("Scratchy", "Black");
Now our cats are no longer mute. We can call myCat.speak(); and it will alert the value “meow”. This makes our Cat constructor function much more interesting. You can see how using this structure you could create constructor functions that have all the power of classes in other languages (plus a few more features, like inheriting values).

Now lets tie up a few loose ends…

So are objects really just a dictionary?
Remember earlier I said that objects were not much more than dictionaries or a map? Well, they are more than just that (see “More information on properties” below) but just to illustrate that they do have dictionary-like behavior, look at the following code (which will work with any of the myCat objects from examples A, B, and C):
    for(var prop in myCat) {
        console.log(myCat[prop]);
    }
This code would produce the following in the console log:
  Fluffy
  White
Notice that we could iterate over the properties in an object and access each of them, just like you could with a dictionary.

So all objects inherit from Object?
When I introduced examples A, B, and C above, I stated, that “almost all objects eventually inherit from Object.” Most likely all the objects you’ll create will inherit from Object (or some other object that inherits from Object). It is unusual to do otherwise, but just to illustrate that idea out here is how you could do that:

Using Example B
Instead of doing var myCat = Object.create(new Object());, you could simply do this: var myCat = Object.create(null);.

Using Example C
After defining the function in Example C, you could simply do the following to make it so that none of the instances created from the constructor function inherit from object: Cat.prototype.__proto__ = null;. The __proto__ property will be explained further in my post on prototypes.

More information on properties
There is another way to make properties, and again the need for this is rare, but it is good to understand that there is more to properties than meets the eye. When we created properties on objects in all of our examples above, it was actually doing much more than you would think. They are all equivalent to doing the following
    Object.defineProperty(myCat, 'color', {
      value: "White",
      writable: true,
      enumerable: true,
      configurable: true
    });
Notice that all properties have three properties themselves that affect the way they behave. The writable property is fairly self-explanatory; if a property is not writable, it’s value cannot be changed in your script after it is created. The enumerable property affects whether the property shows up when enumerating all the properties using for(var prop in myCat). And finally, the configurable property specifies whether the property’s writable and enumerable properties can be changed once the property has been created. Again, the need for these is much less common.

Conclusion
This should give you enough information to start creating your own constructor functions and objects and using working in a way much more familiar if you are used to doing OO programming. If you would like to read a little more about objects, this post (which I also linked above) has some great information. That post is about the new classes coming in the next version of JavaScript, but he had some great examples illustrating objects using the current JavaScript functionality too.

Friday, March 1, 2013

Understanding Javascript Prototypes

Never heard of prototypes in JavaScript? Heard of them but still don't quite understand them? Hopefully this post will help clear up some of the mystery around what JavaScript Prototypes are and why you should care. If you aren't familiar at all with prototypes, they come into play when you start working with objects and inheritance in JavaScript.

So, Why should I care?

It used to be that we could give very little thought to our JavaScript without much consequence since the amount of and complexity of our JavaScript used to be quite insignificant. But, as browser technology has advanced, we now find ourselves in a world that expects rich client-side behavior which requires much more complexity. As that complexity increases we can no longer eschew SOLID programming practices in our JavaScript. Understanding prototypes will clear up a few mysteries that occur as you begin to work with JavaScript in a more object-oriented way.

Prerequisite: Understanding JavaScript Objects

Before diving into this post on prototypes, it will be helpful if you have a basic understanding of what objects are in JavaScript, how they work, and how to create them. If you aren't familiar with these concepts, I highly recommend you read my post on Understanding JavaScript Objects.

In Understanding JavaScript Objects, I used the following examples of creating objects:

Example A
    var catA = {name: "Fluffy", color: "White", age: 0};
Example B
    var catB = Object.create(new Object());
    catB.name = "Fluffy";
    catB.color = "White";
    catB.age = 0;
Example C
    function Cat(name, color) {
      this.name = name;
      this.color = color;
    }
    Cat.prototype.age = 0;

    var catC = new Cat("Fluffy", "White");
In these examples, A and B produce identical results while example C produces a something different. Example B is not very commonly used since Example A is much less verbose and equally useful. While example A is very common and quite useful, it doesn't apply much to this blog post so I will be almost solely working with example C, which uses function Cat, for the remainder of this post.

Why is Cat a function instead of a class?

We know from Understanding JavaScript Objects that Cat is a constructor function. A constructor function really is no different than any other function, in fact the term "constructor function" is just a common nomenclature that suggests that the function will create properties on the object being created (represented by this). In other words, when we say var catC = new Cat("Fluffy", "White"), all that really is happening is the catC object is created and assigned to this for the duration of the call to the Cat function. Therefore, inside the function, this.name = name; is the same as saying catC.name = name. Hopefully, that helps to clarify that constructor functions are not doing anything magic, they are just normal functions that are creating properties on this -- even though we use them in a way that is similar to how classes work in other languages. In fact, using the new keyword, you can create an object out of any function (it just doesn't make sense with other functions).

Cat.prototype.age? What's that all about?

Ok, first of all, notice that Cat.prototype.age isn't really part of the Cat function. It's also helpful to realize when this code gets executed. Seeing the code all lumped together like that might fool you into thinking that Cat.prototype.age = 0; is being called when a new cat is created, which of course, on closer inspection is obviously not true. Usually this code (including the creation of the Cat function above it) is called when a web page is first loaded; thus making the Cat function available to be called. So think about what is happening there. The Cat function is being created and then the age property is being created (with a value of 0) on the Cat function's prototype.

Wait, functions have a prototype? What's a prototype?

Functions can be used to create class-like functionality in JavaScript; and all functions have a prototype property. That prototype property is somewhat like a class definition in other object-oriented langauge; but it is more than that. It is actually an instance of an object and every function in JavaScript has one whether you use it or not. Every function (constructor function or not) has a prototype object instance hanging off of it, interesting, huh?

So, let's talk about how this prototype object is actually used. When you create an object using the new keyword, it creates a new object, passes it in as this to the constructor function (letting that function do to it whatever it wants) and then, and this is the important part, it takes the object instance that is pointed to by that function's prototype property and assigns it as the prototype for that object.

So objects have a prototype property too?

Well, yes but you don't access it the same way and it isn't used for the same purpose as a function's prototype. And this is where a lot of confusion usually begins with prototypes (don't worry if your confusion began long before this, that's normal too). Objects do not have a prototype property, but they do have a prototype. Only, the word prototype means something different when talking about objects than it does when talking about functions. It would be nice if we had a different word, for now, let's call it proto (you'll understand why in a minute). So functions have prototypes and objects have protos. They are very similar, in fact, a function's prototype and an object's proto often (in fact, usually) point to the same object in memory.

An object's proto is the object from which it is inheriting properties. Notice I said it is the object from which it is inheriting properties, not the function or class, it really is an object instance in memory. This differs from a function's prototype which is used as the object to be assigned as the proto for new objects' created using this function as a constructor function. An object's proto can be retrieved by calling myObject.__proto__ in most browsers (thanks IE) and by calling Object.getPrototypeOf(myObject) in all browsers -- I'll use __proto__ going forward for simplicity.

So let's give an actual definition to each of these terms:
  • A function's prototype: A function's prototype is the object instance that will become the prototype for all objects created using this function as a constructor.
  • An object's prototype: An object prototype is the object instance from which the object is inherited.

Back to the examples

All that explanation can be confusing without showing some examples, so let's dive in. If you inspect the prototype of the cats in Examples A and B you get the following result:
    catA.__proto__;
    Object { }
But, if you inspect the cat in Example C you get this result:
    catC.__proto__;
    Cat {age: 0}
Side note: I am using chrome's developer console to execute these statements and I will be displaying the results shown by chrome in grey text as shown above.

Note that in examples A and B, they do have a prototype (__proto__) even though they were not created using a constructor function. Since we didn't specify a prototype for these, they have a prototype of Object. It is possible to create objects without a prototype using this syntax: var myObject = Object.create(null);, but that is very rare and I've never seen a use for it. So barring that example, I think it is safe to say that all objects eventually inherit from Object.

This is even true of catC; look what happens when we inspect catC further:
    catC.__proto__;
    Cat {age: 0}

    catC.__proto__.__proto__;
    Object { }

    catC.__proto__.__proto__.__proto__;
    null
Notice that catC has a prototype (__proto__) of Cat. Actually, to say it that way is not really accurate. Cat is a function, so it cannot be a prototype; remember in the definitions above that a prototype is not a function it is an object instance. This is important to remember when thinking about prototypes -- an object's prototype is not the function that created it but an instance of an object. Since this is important, let's explore it a bit further:
    Cat;
    function Cat(name, color) {
      this.name = name;
      this.color = color;
    }

    Cat.prototype;
    Cat {age: 0}

    catC;
    Cat {name: "Fluffy", color: "White", age: 0}
Look at the difference between Cat, Cat.prototype and catC. What this is showing is that Cat is a function but Cat.prototype and catC are objects. It further shows that Cat.prototype has an age property (set to 0) and catC has three properties -- including age...sort of (stay tuned). When you define a function, it creates more than just the function, it also creates a new object with that function as it's type and assigns that new object to the function's prototype property. When we first created the Cat function, before we executed the line Cat.prototype.age = 0;, if we would have inspected Cat's prototype it would have looked like this: Cat {}, an object with no properties, but of type Cat. It was only after we called Cat.prototype.age = 0; that it looked like this: Cat {age: 0}.

Inherited properties vs. native properties

In the above paragraph, I stated that catC had "three properties -- including age...sort of (stay tuned)"...thanks for sticking with me. Age really isn't a direct property of catC. You can see this by executing these statements:
    catC.hasOwnProperty("name");
    true

    catC.hasOwnProperty("color");
    true

    catC.hasOwnProperty("age");
    false
This is because age, actually belongs to catC's prototype; and yet, if I execute the statement catC.age;, it does indeed return 0. What is actually happening here, is when we ask for catC.age, it checks to see if catC has a property named age, and if it does it returns it, if not, it asks catC's prototype if it has an age property. It continues doing this all the way up the prototype chain until it finds the matching property or finds an object with a null prototype and if it doesn't find the property in the prototype chain it will return undefined.

So that's what prototype chaining is?

Yep. You may have heard of prototype chaining before. It is really quite simple to understand now that you (hopefully) understand a little more about how prototypes work. A prototype chain is basically a linked-list of objects pointing backwards to the object from which each one inherits.

Changing an function's prototype

Remember that a function's prototype is just an object, so what would happen if we started changing the properties of a function's prototype after we created objects from it? Consider the following examples:
    function Cat(name, color) {
      this.name = name;
      this.color = color;
    }
    Cat.prototype.age = 3;

    var fluffy = new Cat("Fluffy", "White");
    var scratchy = new Cat("Scratchy", "Black");

    fluffy.age;
    3

    scratchy.age;
    3

    Cat.prototype.age = 4;

    fluffy.age;
    4

    scratchy.age;
    4
So, notice that changing the age of the Cat function's prototype property also changed the age of the cats that had inherited from it. This is because when the Cat function was created so was it's prototype object; and every object that inherited from it inherited this instance of the prototype object as their prototype. Consider the following example:
    function Cat(name, color) {
      this.name = name;
      this.color = color;
    }
    Cat.prototype.age = 3;

    var fluffy = new Cat("Fluffy", "White");
    var scratchy = new Cat("Scratchy", "Black");

    fluffy.age;
    3

    scratchy.age;
    3

    Cat.prototype = {age: 4};

    fluffy.age;
    3

    scratchy.age;
    3

    var muffin = new Cat("Muffin", "Brown");

    muffin.age;
    4
First, notice that I did not just change the value of the prototype.age property to 4, I actually changed the Cat function's prototype to point to a new object. So while Muffin inherited the new prototype object, Fluffy's and Scratchy's prototypes are still pointing to their original prototype object, which they originally inherited from the Cat function. This illustrates the point that a function's prototype property "is the object instance which will become the prototype (or __proto__) for objects created using this function as a constructor."

One more example to illustrate this point. What would happen if I changed the value of the age property of fluffy's prototype? Would this be different than simply changing fluffy's age? Yes, it would be different. Think about the examples above, and about how age is not actually a property on fluffy, it is a property of fluffy's prototype.

So, given this setup:
    function Cat(name, color) {
      this.name = name;
      this.color = color;
    }
    Cat.prototype.age = 3;

    var fluffy = new Cat("Fluffy", "White");
    var scratchy = new Cat("Scratchy", "Black");
Compare this example:
    fluffy.age = 4;

    fluffy.age;
    4

    scratchy.age;
    3
To this example:
    fluffy.__proto__.age = 4;

    fluffy.age;
    4

    scratchy.age;
    4
These produce different results because in the first example, we are just adding a new age property to the fluffy. So in the first example both fluffy and fluffy.__proto__ have age properties with the vales 4 and 3, respectively. When you ask for fluffy.age, it finds the property on the fluffy object so returns it immediately without ever looking up the prototype chain.

Whereas in the second example, fluffy still does not have an age property, but it's prototype (which is the same instance in memory as scratchy's prototype) now has a the new value 4 thus affecting both fluffy's and scratchy's ages.

Multiple Inheritance

I have to confess, this is not something I use often because I tend to prefer composition over inheritance; but that is not to say it is without a place. Say you want to create a constructor function that "inherits" from another constructor function, much like you would do in other languages when you create one class that inherits from another. Let's look at an example of how you may do this:
    function Animal(name) {
      this.name = name;
    }
    Animal.prototype.age=1;

    function Cat(name, color) {
      Animal.call(this, name);
      this.color = color;
    }
    Cat.prototype = new Animal(null);

    var catC = new Cat("Fluffy", "White");

    catC.name;
    Fluffy

    catC.color;
    White

    catC.age;
    1

    catC.hasOwnProperty("name");
    true

    catC.hasOwnProperty("color");
    true

    catC.hasOwnProperty("age");
    false
Notice that age is the only property that is not a direct property of catC. This is because when we called the Cat constructor function, it passed in our new object (catC/this) to the Animal function which created the name property on the object. The Cat function then also added the color property to catC/this. But the age property was added to the Animal function's prototype, it was never added directly to catC.

Inheriting Functions

In all the examples above, I used properties like name, color, and age to illustrate objects and inheritance. However, everything that I have done above with properties can be done with functions. If we were to create a speak() function on the Cat Function like this: Cat.prototype.speak = function() { alert('meow'); };, that function would be inherited by all objects that have Cat as their prototype, just like with the name, color and age properties.

Conclusion and Credit

If you are like me, it will take some experimenting for all this to really sink in. I'd recommend duplicating the above examples in a jsFiddle or in Chrome developer tools and messing around with them to see what you can do. I think I'm gaining a firm grasp on JavaScript prototypes, but I'm sure I have more to learn. If you find any flaws in my logic, feel free to comment and point them out. And lastly, I'd like to thank Angus Croll and Yehuda Katz for their insightful posts on prototypes. I recommend you also read their posts here and here for another point of view on prototypes. Somehow it helps to have prototypes explained a couple of times from different angles for it to really sink in.

Friday, December 21, 2012

A Nod to Professionalism

When did our industry make the transition to one where foul language, off-colored women-demeaning jokes, and illicit drug glorification became a respectable and celebrated medium for talking about software practices?  Did I miss something?  An announcement or white-paper suggesting the new appropriate way to present to our industry?

I attended the software craftsmanship conference in Chicago last month, and while I enjoyed the conference and found most of the talks very enlightening, I was disappointed with the pervasive lack of professionalism.  Apparently the F-bomb is the new vogue for software craftsmanship because it seemed like about every third speaker felt it necessary to scatter it throughout their presentation.  Also prolific was the inclusion of hard-core drug references.  I didn't realize that was an important part of software craftsmanship.  I recognize that this conference is less formal than some, and a noticeably smaller group than others, but I wasn't the only one who was dismayed by the nature of some of the talks.

The conference had time allocated for lightning talks, and during a break someone gave a lightning talk on this subject.  He talked about the need for professionalism in our industry and lamented the lack of professionalism at the conference.  He specifically mentioned an off-colored, demeaning joke made by one of the presenters.  After his lightning talk I went to shake his hand and tell him I appreciated his courage to stand up for what he felt was important, but I was surprised and pleased to see that I had to wait in line behind several others who were doing the same.

I realize that I am more sensitive to this sort of thing than some and I recognize that others have a different background than I do and there were many who found no offense in the material.  But I wanted to be a voice for those who did.  And hopefully someone, somewhere, will see this post and realize as they prepare their presentation that, while there are many who will not find offense in R-Rated material in a conference talk, there are also many who will.  

I do feel it is important to maintain a decent level of professionalism in our craft.  I hope that this was an anomaly and not the beginning of a new trend.  

Monday, October 1, 2012

Right-Sized Methodology

In a recent agile round-table meeting that I attended in Salt Lake, Mike Clement (@mdclement) suggested that we often tend to lose focus of the original goals of Agile as laid out in the Agile Manifesto.  I have to say, I love agile, and I particularly love XP (which actually pre-dates Agile). And, to be totally frank, deep down, I am probably of the opinion that the XP principles are critical to Agile success and possibly superior to other methodologies.  But that kind of makes me part of the problem.  One of the agile principles in the manifesto states that we should value "Individuals and interactions over processes and tools".  So to say that XP is superior seems to be more focused on the process than on what best facilitates a focus on "individuals and interactions." And even once a methodology is chosen it needs to be constantly reviewed and adjusted.

The truth of the matter is that teams should create a methodology that fits the unique environment they are in; and that methodology should focus on realizing the most possible value from the ideas in the agile manifesto.  Every software team exists in an environment that is unique to their team; that uniqueness comes from a host of different variables including things like:  company size, team size, company and team values, individual personalities, company goals, etc.  And that means that the methodology they develop (and continue to refine over time) should be a methodology that is tailored to their unique circumstances.

Our industry is still learning and I think Agile is an important step on that path.  As we come appreciate what agile gives us we do need to be careful that we don't become so focused on our process that we forget about the values.  We need to frequently review how we are writing software and determine if there are unnecessary or less-effective processes that are adding dead weight to our chosen methodology.  The objective should be to design a methodology that is as lean as possible without sacrificing important values.

This is one thing that I love about working at Pluralsight.  Our methodology is the lightest methodology I've ever experienced.  But our approach wouldn't work everywhere; we're lucky that our company environment allows for such a lean approach.  This is due to a few factors, including:  
  • The pluralsight partners are developers, so we speak the same language; 
  • Keith, our IT manager, is not just the CTO but also a partner; 
  • our dev team, for now, is small (4 developers plus Keith, who used to do more development and is now moving more into directing the team); 
  • and our dev team has a lot of experience (we each have 13+ years experience and several years experience experience with agile).  
Our methodology is similar to XP (TDD, pairing, acceptance tests, CI, frequent releases, etc) but much lighter in some areas.  Here are some areas where our environment has allowed us to be more lean:

The Planning Game
Since the person who manages our team also happens to be a Pluralsight partner, he already completely understands the company vision.  He also has been very involved with the software (he wrote the initial software and still gets involved in the code from time to time).  Having someone that understands both sides so well allows us to cut some corners.  This, combined with the fact that our team is still small, has allowed us to completely forgo sizing meetings.  The partners discuss and develop the IT roadmap and in their meetings Keith can provide feedback from a technical standpoint without having to do a round-trip to the dev team. We use a kanban board and we just put the stories on the board and Keith prioritizes them based on company priorities.  When we're done working on a task, we just grab the next task.  And this all works very well without the devs ever having to be involved in a planning meeting.  Normally, this would make me nervous because the developers need customer affinity, but the awesome thing is, we still get that because Keith has the company vision and shares it with us freely in our "stand up" meetings.

Daily Stand-Ups (aka scrums)
We do have them, every day, but stand-ups are called stand-ups for a reason, right?  You're supposed to stand up because it keeps people from going on and on about the details of some problem since people get tired of standing.  Some people might be shocked to learn we never stand-up in our stand-ups.  And some of our stand-ups do go longer than a "status update" meeting should go.  But our stand-ups are more than discussions about status and roadblocks -- because our team is so small, we can afford to talk architecture or business in our stand-ups.  Although there may be some occasions where part of the discussion isn't totally applicable to everyone in the meeting, I find our stand-up meetings to be very valuable.  It is a great opportunity for the team to talk together about important directions and even get into the details of some of the roadblocks.  It is also a great opportunity for Keith to share the business vision and direction changes.  This meeting ends up taking the place of at least 3 meetings (stand-up, architectural design, and parts of the planning game).  And because our team is small, we still manage to typically get it all done in under 30 minutes each morning.  I realize that for some 30-minutes is an awfully long stand-up, but this is much more valuable than just a stand-up.  We won't be small forever, so this may have to change some-day to a more traditional stand-up supported by other meetings, but for now, it's awesome.

Short Iterations
I've worked on teams that have had 1-week and 2-week iterations.  The odd thing about our environment is we don't really even have defined iterations.  I realize this may sound like cowboy coding, but it really isn't.  Because we don't need a planning game (for the reasons discussed above), there is less of a need for defined iterations.  We are able to keep this from becoming a cowboy coding shop because of other practices we follow closely (TDD, paring, acceptance tests, etc.).  Additionally, the partners understand the importance of quality so the devs are completely comfortable (and actually encouraged) to slow down and do it right.  When we finish a task, we push it to our repository, let our CI builds run, and if it is a meaningful enough change we push it to our staging environment where the changes are QA'd and accepted by other developers and once it passes it is pushed to production if everyone agrees its safe to push all the current changes. 

Collective Ownership
In Extreme Programming Installed, Ron Jeffries says "I'm not afraid to change my own code.  And it's all my own code."  This is a benefit that comes from pairing and switching pairs regularly.  When we have to work on code we're not familiar with it takes longer and we're more timid.  Because our team is so small, this one just comes naturally.  We all get into the various parts of the code eventually and the more we do, the more comfortable we are to make changes.

Pluralsight is growing quickly and it seems inevitable that our team will grow too.  As our team grows, we will no doubt have to make changes to our process and add additional pieces that we don't have now.  And that's ok, in fact, that's how it should be -- we should always be tailoring our methodology to fit the current needs of our team.  But for now, I am totally loving how lean we can be.

What are your thoughts and experiences with designing a methodology to fit your needs? 

Tuesday, August 14, 2012

Is TDD a Silver Bullet?

I recently read this post by Jeff Langr and really appreciated the comments made by his previous co-worker, Tim. Tim clearly was not sold on TDD right from the beginning, but his comments, after being encouraged to do it for two years, are insightful.

In the article Jeff asks Tim, "What did you finally see or recognize in TDD that you initially couldn’t see?" The bullet list of reasons why he likes TDD very closely matches my own list.  I also find it interesting that Tim concludes his findings with the statement that TDD is not a silver bullet when he is clearly a full-on advocate of TDD. But it is true what he says, writing software is challenging, even with TDD. In fact, for a while when you are learning TDD, TDD itself can be very frustrating.

Tim mentions in his response to Jeff that it took about 2 years for it to really sink in. I can echo that statement as it seems the same for me. But, I would like to clarify that I was able to write fairly decent tests after a couple of months and was able to do TDD fairly well within a few months, but it really does take about 2 years before you really gain that confidence about TDD where you feel like you really "get it".

Alistair Cockburn talks in some of his books and in this post about the three different levels of learning referred to as Shu, Ha, Ri.  He talks about how, when we are learning new skills, we all pass through these three levels of learning.

During the Shu phase we are building our technical knowledge.  We are trying to learn the rules that define the skill and we find it very frustrating when someone breaks those rules because it is difficult for us to understand why we would in this case but not in another.

During the Ha phase, we begin to reflect on what we have learned in the Shu phase.  Everything we have learned so far has been committed to "muscle memory", as Cockburn states it, and we can now begin to "reason about the background behind these techniques".

In the Ri phase, the student has mastered the skill at such a level that he can begin to "think originally" about the skill and produce new and better forms of the practice.

It seems to me that TDD has an incredibly long Shu phase.  And, with TDD, I think there is a phase, which lasts about 2 months, that predates the Shu phase.  A phase which could be aptly labeled the, "what sort of voodoo magic is this crap?" phase.  For some of us our heads just spin for about 2 months during this phase.  But then, we begin to grasp the basics and we are fully into the Shu phase where we can look at other code samples and reproduce the same effect in the code we are trying to test.

It does seem that we stay in this phase for quite a while, probably around 1-2 years until we begin to really feel we understand and champion the reasons why we are doing it.  Perhaps this is why some teams struggle with picking up TDD, especially if they don't have someone who is already in the Ha or Ri phase to help them along.

So it is true that TDD is not a silver bullet, if what you're hoping for is something that makes software development easy (which is not to say it doesn't make it easier).  Writing software is complex and  sometimes frustratingly difficult even when done right.  But I agree with Tim: it makes software more maintainable, cleaner and better architected; it makes writing software faster; it gives me more confidence; and it is more fun to write code with TDD.  If your team is just starting to experiment with TDD, stick with it even if it seems foreign and more difficult at first.  In the end, I hope you'll find what Tim and I have found...once you get it, you love it.