The function definition in Javascript

I highly recommended Douglas Crockford's book "Javascript:The good parts". In the page 133 of the book, the author mentioned 2 ways of defining a function:

• use function statement,
• use function expression

Their results are exactly the same. For example,
Function statement:

	function foo() {
	alert("foo");
	}

view raw gistfile1.js hosted with ❤ by GitHub

Function expression:

	var foo = function() {
	alert("foo");
	};

view raw gistfile1.js hosted with ❤ by GitHub

The above two have the exactly same result. they will both define a function foo. But I found there are still one difference: scope.
The function statement is globally scoped, it can be put anywhere in the javascript, and you can call the function before or after it is defined.
For example:

	//call before function foo is defined
	foo(); //=> alert("foo");
	function foo() {
	alert("foo");
	}
	//call after function foo is defined
	foo(); //=> alert("foo");

view raw gistfile1.js hosted with ❤ by GitHub

But in function expression is different, the function call statement must be after the function is defined, otherwise the function call will be failed.
For example:

	//call before function foo is defined
	foo(); // will fail, because foo() is not defined.
	var foo = function () {
	alert("foo");
	}
	//call after function foo is defined
	foo(); //=> alert("foo");

view raw gistfile1.js hosted with ❤ by GitHub

When you think a little deeper, the error of function expression make sense, because the function expression means first declare a variable, then assign it with a function object. Why it failed before the function defined is because the variable is not declared and assigned yet.

So if you use the function expression to define a javascript function, you need to aware this issue.

Learning javascript: understanding prototype property

Prototype in javascript is so important, because javascript implements the object inheritance via prototype delegation. Here I tried to summarize what I found for the javascript property. The examples I used are tested on Firefox Javscript shell .
Please note that in Javascript function is also an object, so here function and function object are interchangeable.

1. Every function object is automatically created with its own prototype property, the prototype property itself is an javascript object.You can add property or functions to the prototype property via function object.
Example:

	var F = function() {};
	F.prototype.a = 'b';
	F.prototype.a; // b

view raw gistfile1.js hosted with ❤ by GitHub

2. When a object is created by using new keyword, it will get the prototype object from the constructor function;  created object can not access prototype property directly like function object, but it can access the property of the prototype object:
example:

	var s = new F(); // s get the F.prototype
	s.a; // return 'b';
	s.prototype; // return undefined
	var string = new String(); //get String.property
	var array = new Array(); //get Array.property
	var num = new Number(); // get Number.property

view raw gistfile1.js hosted with ❤ by GitHub

3. When the created object instance read a property of the prototype, which is directly linked to the prototype object of its function constructor; while you want to modify the property, you end up by creating a new property in the object itself, which will not impact the same property name in the original function prototype. I believe javascript in this way implements the OO inheritance and overriding.
Example:

	var F = function() {};
	F.prototype.a = 'b';
	var s = new F();
	print(s.a);
	print(s.hasOwnProperty('a')); //false
	s.a = 'c'; // object s will create its new property 'a'
	print(s.a); // c
	print(s.hasOwnProperty('a')); // true;
	print(F.prototype.a); //b; property in F is not changed

view raw gistfile1.txt hosted with ❤ by GitHub

4. The function object prototype property, which itself is an object, its default value contains only one hidden property: constructor, whose value is the same as the function itself.
Example:

	var F = function() {}; // This is a function object.
	var p = F.prototype; // This is the prototype object associated with it.
	var c = p.constructor; // This is the function associated with the prototype.
	var c === F; // => true: F.prototype.constructor==F for any function

view raw gistfile1.txt hosted with ❤ by GitHub

Code is constraint

Last week I watched Michael Feathers presentation: Code blindness.This is a great presentation, and it inspired me to think deeper.

Before I think code is important from the programmer's perspective: craftsmanship, and professionalism. But it seems quite far to the managers. They don't know understand it and don't know how to connect this with their daily management.

Today I would try to think from manager's perspective: borrowing the idea from theory of constraints, I will say code is just another constraint, like other constraints manager usually considering: time, budget, people. More specifically code quality will impact developers productivity and on time delivery.

We know that the clean code base will easier to understand, easy to make change, and easy to maintain,but bad code base will hard to understand, hard to change, and hard to maintain, which greatly slow down developer's productivity.To avoid this happens, we have to deliberately keep code lean.

There are two main metaphor to support the clean code:

• Metaphor of technical debt: code base is like technical debt, we have to pay off first by taking effort to refactoring, otherwise it will become harder and harder to change and maintain in future, so refactoring is the interest we pay for the debt.
• Metaphor of software entropy: code base is like entropy, by nature it will gradually go to messy, we have to constantly refactoring and keep our codebase clean.

So we can get the conclusion: code can be asset if it is clean; and can be debt as well if it is messy.

So far we know that code is very important to developer's productivity, it should be consider as a constraint by the manager. But I found many managers are totally unaware of this issue:
They just assume developers are all professional and their code will always good enough;
They only care the schedule, only care something get done, but does not care if the code is well maintained or not.
And since managers unaware or ignore this issue, they might make decisions to make code base even messier, for example,
- they will pressure developer to push them make quick-and-dirty fix, which cause the long term issue;
- They do not care for the code, so they measure the performance only by task been finished, not by how good the code is written, so we can imagine developer will not actively care for the code.

Code is important, but if you unaware or ignore it, then you will not manage it.
If you don't manage it, then you will finally lost the control and then we will get real problems.
When you have the problems, but you don't understand the root cause is code quality, then you probably trying to solve the issue in a wrong way.
I heard so many times from managers said something like "we need to work harder", "we should work more careful", which are totally useless slogans.

Suggestions

1. Manager should aware the code quality's importance, bring the connection between good code quality to developer's productivity and developing schedule.
2. Manager should cover code quality into their daily management, right now there are so many different tools to do code analysis and measurement.
3. Manager should create a culture to encourage software craftsmanship, clean code is a foundation of good software product,  clean code fit nicely the "build quality in" lean principle.

Making developer multitasking is a bad idea

Following is copied from a job description for a mobile software developer from my previous employer QuickPlay Media:

"Well organized with the ability to effectively manage multiple projects simultaneously. Extensive experience in a fast-paced deadline-oriented environment".

When I first look at it, I was really surprised by the word "multiple" and "simultaneously", it is pretty obvious that they requires developers to be able to do multitasking jobs. Today I would like to dig this topic a little bit.

What does "manage multiple projects simultaneously" exactly mean?
- Working project A for 5 minutes, then working on prjoect B another 5 minutes, and project C for another 5 minutes?
- Or when you are working on project A, then interrupt by project B, you have to suspend the project A, then switch to project B;
- Does it mean the developer has more project working simultaneously, the better for his performance review?
- Does multitasking really improve the productivity? get faster delivery?

This idea is totally wrong
In the last 2 years I read a lot books about agile and software craftsmanship, so I am quite confident to say this is totally wrong, it will only make things worst!

Fist it is against human nature. Human is not machine, he is non-linear, a person can only focus on one thing at a time. Interrupt and context switching is very expensive. The book Pragmatic Thinking & learning and  peopleware cover this topic, and explain why managing focus is so important to maintain a higher productivity. and that is the reason why the Pomodoro technique will force you only focus on one task in each 25 minute session. Managing people's focus is the key of improving his productivity.

Second it is against the agile principles and and other proven theories. The goal of agile is to deliver the product as fast as possible, but the interesting thing is the agile trying to reach this goal by limiting the Working-In-Progress items (WIP).  Scrum is trying to limit WIP in one iteration, WIP is called inventory in Lean, which is a waste and should be limited. Limiting WIP is the key concept of Kanban technology. and in theory of constraints also proved that putting to many task in the queue will only slow down the productivity.The reason is pretty obvious, think about this scenario, if you have 3 projects, each will take one week. If you work sequentially, you will deliver one project after 1 week, 2 projects after 2 weeks, and you will get 3 projects after 3 weeks. But if you work simultaneously, you will get any project done until after 3 weeks, but considering the context switch cost, it will take you longer time to finish all 3 projects. So based on Scrum, or Lean/Kanban, or Theory of Contraints,  working simultaneously will not deliver fast, it will only delay the delivery time.

Third is it is a shift burden to from mangers to developers. Managing backlog is manager's responsibility, but requiring developer multitasking means putting some more backlogs into developers. It might looks better for managers, but actually it is bad, since those extra backlogs are either under working or putting into developer's own backlog. This is actually hide the visibility, which is even harder for manager to track the progress. I can feel that the multitasking is a solution which managers are trying to solve too many backlogs, but it is a bad idea, since it only move the backlog from manager layer to developer layer, which making things even worse; the manager should figure out the root cause and find a true solution to increase the burden down rate or increasing the productivity. I like to call this issue is leaky management issue(copied the idea from leaky abstraction from OO design), because it is supposed to be solved in the management layer, but it leaks to the developer layer.

Based on the above analysis, I can feel multitasking will generate following result:
developer will have low productivity, projects will get more delayed, developer have to work harder and over time; since more projects get delayed, so manger put more projects to developer to work simultaneously, then becomes a positive feedback loop, which will make things even worse...

Summary
I feel very sad for my old colleagues, because they are not treated well;  and I feel sorry for my ex-managers, because they are unaware of the basic principle of agile. To make a developer working efficiently, the only thing is trying to make him to work on one thing only. I strongly suggest QuickPlay to remove multitasking in its job requirements, but removing that from managers minds are much harder.