Node.js file system API provide a bunch of functions to read/write files. One of them is the fs.mkdir(path, [mode], [callback]). However, this function itself does not provide any option for you to create a directory if the parents folder is missing, it’ll trigger an exception if you trying to do so. In another word, you can’t do something like “mkdir -p DIR”.

However, the callback function is an extreamly useful feature to extend this function. In case the fs.mkdir failed, it passes an error object into the callback function. Like this:

var fs = require('fs');
fs.mkdir('parent/child', function(error) {
  console.log(error);
});

You’ll see it print an object looks like:

{ [Error: ENOENT, no such file or directory 'parent/child'] errno: 34, code: ‘ENOENT’, path: ‘parent/child’ }

Good, now we know in the case of missing directory, we’ll get error code 34. What if we catch the error and try to recursively create it’s parent, then create the directory again? Everybody deserve a second chance, right?

var fs = require('fs');
var path = require('path');

fs.mkdirParent = function(dirPath, mode, callback) {
  //Call the standard fs.mkdir
  fs.mkdir(dirPath, mode, function(error) {
    //When it fail in this way, do the custom steps
    if (error && error.errno === 34) {
      //Create all the parents recursively
      fs.mkdirParent(path.dirname(dirPath), mode, callback);
      //And then the directory
      fs.mkdirParent(dirPath, mode, callback);
    }
    //Manually run the callback since we used our own callback to do all these
    callback && callback(error);
  });
};

Now you can run it like this;

fs.mkdirParent('a/b/c/d/e');

The longer this circumference is, the more knowledge you have, the more you realize you don’t know about.

A person have a large circle knows a lot he/she don’t know, so one have to be humble. A person have a small circle knows a little, so one think the whole world is in one’s hands.

There are couples of things people either intentionally or mistakenly overlooked when they see story points estimation. Or maybe, they just misunderstood the the idea of story points estimation. I’ll try to explain the idea of story points from different perspectives based on my limited experience in Agile.

1. Story points is about the EFFORT of your works

Imagine you are working on a project moving goods from San Francisco to New York city. And you them an estimation about how long the project gonna take. What if I tell you by using different means of transportations, the duration of this project will turns out different? Yeah, you might say that’s bullshit, I know that. Right, and I think that’s also exactly what happen in software development process. The duration of a project you communicate with people should based on a fact that which way you are using to do it.

It’s been over half century since software industry commercialized. And there is nothing wrong or surprise that people’s mind are set into a concept of software development is all about time, time is money. On the other hand however though, you can ignore but cannot eliminate a fact: The amount of resources and means of production you use is deeply impact the duration of your projects.

The idea of using story points instead of days and hours to estimate a project is that story points are talking about the effort of the work, it’s a pure fact. And sometimes story points have something to do with complexity, because the complexity of a work affect the effort you need to put in, although story point is not exactly complexity itself. The story points in the previous example is the distance from San Francisco to New York city, and this fact does not change along with the means of transportation you use. BTW, You might argue the distances of using air or ground is absolutely different, but I’ll argue we all using air, there are still different airplanes and airports, now the game is fair. By preserving the original, raw, pure fact(in this case, distance) into your estimation, you can always CALCULATE the duration of your project with the distance divided by the velocity of your transportation.

2. Story points are RELATIVE numbers

And so there is confusion about what is 1, 2, 3… story points actually means, how do they match back to the effort of the work. In my opinion, story points do not match to line of code, hours of work, nor complexity(well, OK, somehow related to complexity, but not exactly nor directly). Story points are relative to each others. To understand what 3 points means, a whole team must work together to come with a agreement about what 1 points means. Then 3 points story means it takes 3 times more effort to finish comparing to a 1 point story.

And each team should have their on sense of how big a work can means 1 point. Which makes the concept of story points is not universal consistent, it’s per-team and per-project. But that will not mess up the final duration calculation, because for each team on each project. You have your velocity information, and of course, this velocity is also per-team and per-project.

3. Story points cannot and SHOULD NOT carry clear duration information by themselves. That is not the intention of story points. However, when calculate project duration, they are REQUIRED

Using the example before, when you talk about the distance from San Francisco to New York city, you don’t explicitly saying any time, even though this distance might IMPLY a little information about timing. Such as if you deliver a from San Francisco to Los Angeles comparing to New York city with the same way, you can sort of figure out deliver to Los Angeles probably will take less time. But this timing information is fuzzy and talking about this timing issue, you must assume the transportation being used.

As I mentioned above, in order to figure out the duration estimation of a project, you must know the velocity, which is how many story points your team can consume in a period of time. Then use the total amount of story points out there divided by the your team’s velocity, then you get the estimated duration.

And the reason why I think story points should not carry timing information is because the the productivity of your team is bouncing ups and downs. People may out sick or vacation, they may leave the team and new people may join the team. Same as your truck moving goods from San Francisco to New York city, it’s not always at the same speed. To let your client know the most updated delivery time estimation, you MUST recalculate it frequently by using the rest of the distance you haven’t finished(the story points you left), divided by your current velocity. As what the title of this article says, in Agile process, the final estimated time is just a CALCULATED RESULT from the total amount of work and the velocity. For each little piece of work, they should be estimated using the concept of how big it is, which is story point.

I won’t getting into the detail of team’s velocity in this article, however, there are plenty of articles and books out there your can reference.

You know what? Before you thumbs down this formula, I believe it’s being used to calculate the duration in classical physic science, and most importantly, in WATER FALL. But instead of story points, they have a different name: man-month.

4. Story points cannot and should not eliminate individual diversity in estimation, but encourage collaboration

The way to come up with these points for user stories is to have sizing meeting. Each sizing meeting can have various number of people participate in, depends on the amount of the stories need to be sized, people’s expertise, and the number of people in the team. And in the meeting, people vote on each user story, of course diversity happen, then they discuss, and finally come up with an agreement, story points logged. I am not gonna describe how to run sizing meeting exactly, there are plenty of resources you may reference.

The idea of sizing meeting is the team work together to decide how large each story is, and put the story points into each story. Some people may argue that because each team member has different level of proficiency on different skills, therefore in the sizing meeting it’s hard to coming up with agreement about what the size is for each of the stories. Well, I think the cause is true, but the effect is a straw-man. Because if you estimation work in other non-Agile way, if you include more than 1 person in an estimation, diversity happen right away.

First we must look at the philosophy of Agile, is to encourage collaboration, which is the whole team work together as an single entity. It is true that each person is different, and they should functioning differently in a team depends on their expertises. However, these diversities should not drive your team work against each other, the diversities should drive your team WORK TOGETHER. Because no one can do everything by himself/herself.

So back to the practice, in a sizing meeting. Team members vote on the sizes should help each other figure out the truth. Let’s say the one voted a smaller number can say: Let me tell you a shortcut to do this you may not noticed. And the other one voted a larger number can reply: You maybe right, but let me tell you a complexity you don’t know about. And people should keep in mind giving up their own votes of on a couple of stories to agree with other people is not a individual failure, it’s the success of the team collaboration.

But not matter how hard we try to do things right, bad things happen sometimes. In the case people’s votes are too diverted and they are not willing to give up their votes to agree to each other, the lower bidder get the job. Same as construction. Because from the whole team standpoint, it’s more economy to have the people confidently insist the work is smaller to do it, because they might know the shortcut, have the expertise and know what are they talking about. A good example is if there is a graphical work the database architect insist is 3 points and the graphical designer insist it’s 1 point, then let the graphical designer take that 1 point and do it is making more sense than fighting forever. And BTW, if this sizing meeting is all about end users UI, you may consider don’t invite database architect, you don’t need to wasted his time.

Further reading

Mike Cohn’s blog posts about story point http://blog.mountaingoatsoftware.com/tag/story-points

To be continues…

describe "launch the rocket" do
  context "all ready" do
  end

  context "not ready" do
  end
end

So what’s the difference between “describe” and “context” really?

According to the rspec source code, “context” is just a alias method of “describe”, meaning that there is no functional difference between these two methods. However, there is a contextual difference that’ll help to make your tests more understandable by using both of them.

The purpose of “describe” is to wrap a set of tests against one functionality while “context” is to wrap a set of tests against one functionality under the same state. Here’s an example

describe "launch the rocket" do
  before(:each) do
    #prepare a rocket for all of the tests
    @rocket = Rocket.new
  end

  context "all ready" do
    before(:each) do
      #under the state of ready
      @rocket.ready = true
    end

    it "launch the rocket" do
      @rocket.launch().should be_true
    end
  end

  context "not ready" do
    before(:each) do
      #under the state of NOT ready
      @rocket.ready = false
    end

    it "does not launch the rocket" do
      @rocket.launch().should be_false
    end
  end
end

This code is more readable than wrapping all the stuffs with “describe” blocks. Because when you read the tests under “context”, you know they are all testing the same thing the “describe” talk about. And you know a “context” is to setup the state of your object, in this case @rocket.ready which will effects the behavior of @rocket.launch() that gives you a conclusion, right away, without scanning the code back and forth.