The Dreadful Estimates

Well the title of this post it self is self explanatory aint it ;) ... We all know how hard it is to estimate something in our own lives. Moms will always ask how long will it take to clean your room, wife will ask how long will it take for you to get home, if you ask your dad for something he will ask how much does it cost.. So as the pattern goes on you can see all of us live in a world revolving around estimates. The same comes into play when estimates need to be made when an IT project is taken into consideration. Ofcourse all of us know how much of a dreaded task estimations can be mostly due to the fact of uncertainity that is filled with making some or most of the estimates. Aim of this post is to help all you poor souls and to take you out of your misery of doing estimates and doing them right:D ..

First of all what needs to be done is basically jot down all the user requirements and break them up into user storys which refelect all the functionality which needs to be provided by the software we are doing to build. A user story can be just a short 3-4 line description of what the functionality is all about with a title preceding. For example a typically user story will look like the following;

Title - Log-in users to the system
Description - Provide authentication capabilities to users loggin in to the system via a login menu.

That of course is one simple user story but you get what im trying to imply here yea ;) ... Ok so moving on, the next thing to do is to get together with your team with all the user storys you have come up with after many initial discussions with the customers and to decide an appropriate estimate for each user story you have defined.

One fun way of doing this would be by putting the user story on the table, explaining to your team what is exactly required by the user story and ask each one to provide an estimate of how long it will take to finish that specif story. Then you look at the spread of values taking everything into consideration. You then ask each developer based on what assumptions each of them came up with the estimates. What you do then is clarify each assumption with the customer that your team has come up which even you cant provide an accurate answer. Note that this is a pretty important step because if you go ahead with many assumptions to the coding stage that runs a high risk factor of the resulting software not being what the customer really wanted. Hence it is always advisable to talk to the customer up front with any assumptions you have and to get it clarified at that point of time so as to minimise the risk factor.

But of course at times even the customer would not know the correct answer to an assumption in which case what you should be doing is noting it down so that you have a track of any risk factors associated with each user story.

Then after going through the cycle of estimation and assumption clarification you ask your team to make another estimate now that most of the assumptions are resolved. Then you take the spread of estimated values which in this case would not be as much dispersed as before and take an average value from those values and come to an agreement with your team members of that value. Ofcourse one thing to note is this time should include not only the coding time but also the design, testing, integration, documentation(if needed) and deployment time.

If for some reason the estimated number of days for a user story is more than or equal to 15 days that usually means still there is something wrong somewhere. So what do you do in this situations? Well you got two options;

1. Break down the user story into smaller functionalities, thereby spreading the number of days among the sub functionalities.
2. There still might be unanswered assumptions that might fact for this estimate hence it is time to go back to the customer again and to further clarify those assumptions which would eventually lead you to re estimate the number of days.

Hence any of the following two ways can be used. After that what you do is add up all the estimated values you have come up with for all the user storys which would then make it possible for you to give the customer an estimated for the whole project which you feel confident about because you and your team have nailed down almost all of the assumptions and are pretty confident with the estimate.

So you come up with the estimate for the whole project. What if the customer says that the number you came up with is too much???? Yikes, didnt think of that now did ya? Well that my friend is a topic of its own. So stay tuned for the next post to see what you can do to overcome/handle such situations.

Iterative Software Development Cont.....

My last post gave an introduction to what iterative development is all about and what kind productivity and value addition it brings to the table. In this post i want to address the questions unanswered in my last post. Cant keep the readers in suspense now can i ;) ... But hey everybody likes a little thriller every now and them right? :) .... So what were the questioned that were unanswered in my last post? Ok ok if your bored to go back to it and check it out let me list it down here again :D....

• How to approach iterative development
• How to project your iteration size
• How to incorporate new customer changes half way through an iteration

Taking first thing first, the way you should ideally approach an iterative development process is by first analysing the initial customer requirements you gather and breaking down those features with respect to the application scope. Then what you should do is to weight every feature according to the priority level (High/Low) as perceived by the Customer and estimate the number of development days each feature will take to complete.

This process includes the asnwere to our second question which is how to project your iteration size. So you can see them both as interelated questions. Iteration size normally is recommended to be best kept at 20 working days(i.e one calendar month). But ofcourse this is definitely a varying factor depending on the complexity and the size of the project.

What you do after you decide on your iteration size is to try to calculate what features can be included in the first iteration which keeps in track with the iteration size you specify. But also you should keep in mind to put in most of the high priority tasks to each iteration as possible. Sometimes there maybe some low priority features that need to be provided before you can continue with a high prioratized feature in which case it is acceptable to include low priority features into an iteration.

Going on to my last question which is what you do if the customer comes up with a new set of features while you are in the middle of one of your iteration. Again you should go in the normal flow as explained before and weight new features accordingly and then try to see how it best fits the current iteration. If it is possible you could always push back some of the planned features of the current iteration to the next iteration and incoporate the new features whilst keeping the iteration size intact. Then you could ask the question what if its the last iteration and the customer comes up with a new set of features. Well in this instance you have to come into an agreement with the customer as to what is realisticaly possible to achieve for the given deadline and either try to move the dead line or add more developers or ask the current team to work long hours to make the current deadline. But in my perpective i do not believe adding more developers or making the existing ones work long hours will do the project any good as overworking burns out developers which in turn will lessen their productivity in the long run. And adding new developers in the last iteration is or for that matter in the middle of the project is a very decisive decision to make because according to what is stated in the book The Mythical Man Month by adding new developers you are adding n(n-1) / 2 communications channles within the project where "n" is the number of people in the development team.

Hence it is always best to try to negotiate with the customer on the current situation and try to shift the deadline to a latter date or to come to an agreement and compromise some features as deemed appropriate by the customer that can be included in later versions after the deadline.

Well thats about it for now about iterative development. Two pretty long posts on iterative development huh?... :) .. Guess you guys are now getting sick of reading about iterative development. So ill try to blend in something different in my future posts to come.

Until then its adios from my side and happy development (hopefully iteratively :D )

Iterative Software Development

Ive been wondering why sometimes we in our projects face tight dead lines and if there is any way we could overcome such situations. In my current project we are kind of facing a tight deadline situation as well and this led me to investigate on this topic of how the development process should be organised so that these kind of issues can be resolved before hand as much as possible.

My eyes caught up on a process known as iterative development. For some this definitely is not a new concept, if so please do ignore this post :) . Iterative development as i see it is not necessarily a process by itself but we can incorporate it to any of our current processes in order to maximise efficiency and throughput.

If we look at a project at a very basic level what needs to be done in order to complete it successfully is to develop a product/application which meets all/most of the user's needs within the time line given by the user and within the budget specified. How some people approach this kind of problem is by trying to figure out all of the customer requirements before even writing a single line of code or design document and spend a considerable amount of time in that process. But what they later find out is that customer requirements never stay static because of the fact that even the customer would not know what he wants as the project is initiated. What this kind of process results in is developing a product/applications which does not meet most of the user's needs because of the fact that we lose contact with the customer after the intial rigorous requirement gathering phace and only come into contact once we go through the full cycle of the the development process.

But what we need to do is to break up whole project into smaller iterations and thereby do repetitive requirement,design,development,testing cycles in each iteration. What this kind of approach gives is the ability to get customer feed back after each iteration where the user can say if we are on track according to his/her needs or not and we can then refine our next iteration incorporating these changes. By following an iterative development process we surely are able to stay on track in most cases and meet the project deadlines without out burning the development team.

More on how to approach iterative development and how to incorporate new customer changes half way through an iteration and how to project your iteration size can be seen in the coming articles... So stay tuned ;)

JavaScript instance methods vs Class methods

Javascript instance methods are those that start with the "this" keyword where as class methods start with the prototype keyword. The difference between the two is that given an object instance methods are created per object whereas class methods are only one per class and not per instance so you will avoid creating duplicate object methods. Examples of the two are as follows;

 

1. Instance method example

 

    this.getName = function(){return this.name;}

 

2. Class method example

    //ObjName is the name of your object

    ObjName.prototype.getName = function(){return this.name;}

 

There is another method which is a class only method. The only difference with that is that it cannot access instance variables like the class method above but can only access class only variable. Example is as follows;

 

//this is a class only variable

ObjName.prototype.name = 'test';

/*Note that to get the class variable you have to drill down to the prototype object and you cannot access instance variables in class only methods. Only difference between this and the previous method as you can see is that it does not include prototype keyword.*/

 

ObjName.getName = function(){return ObjName.protype.name;}

 

But one thing to keep in mind is that the fact that the prototype keyword is not sometimes supported by older browsers.

Java Script Date Object

Java script consist of a Date object which is kind of similar to the Java Date object where as it uses the time since the epoch but some utility method available in the Java language are not available in the JS Date object version. Some of the utility method which i cared to share are as follows;

getDate() - Get the day of month e.g 1-31
getMonth() - Gets the month of the year. Note that it starts with 0-11 So Jan is basically 0.
getFullYear() - Gets the current year as a four digit character

Also we can pass the date as a string literal to the date object as new Date("08/09/2007") which it will convert to the intended date time. It also consists of a toString method which is a bit too cryptic and should not be used when showing specific date objects. The above in-built methods should be used instead to show the user a properly formatted date.

How do you get teh number of days between two days;

This can be done as follows;

//Assuming that date 2 is after date 1
function(date1,date2){

return Math.round( (date2-date1)/(1000*60*60*24));

}

Java Script Array Sorting

Java scripts have intrigued me!!!As so far as me going to the book store and selecting java script books to learn it the old fashioned "Off the shelf" way ;) ... So some of my posts from here onwards will contain a mix and match of java scirpt/java so any anti javascript ppl please dnt take it personally :D.... I never knew java script had array sorting like whats available for us java developers. Two ways this can be accomplished..

Method 1:

//Sorts values in descending order
function compare(val1,val2){
return val2-val1;
}

var myarray = new Array([1,3,7,10,32,45]);
myarray.sort(compare);

Thats about it to do sorting using arrays. Of course you could have just used myarray.sort() which would have used the default sorting mechanism and sorted the array in ascending order. You could debate here saying why do we need to define a new method just to get the sorting done. Bit too much code to do a single sorting function. Well look no further method 2 below shows how to do the same thing as above with just one line of code using the function literal capability of Javascript.

Behold Method 2!!!!!!! (Drum roll please)
Method 2:
myarray.sort(function(val1,val2){val2-val1});


Thats about it for now. But more to come very soon guys. So stay on the look out for all those Java script newbies like myself :).

Cheers

String concatenation and String builder confusions resolved

There was a very hot debate going on about String vs String builder and doing string concatenation within the append method of the String builder. I then researched this topic on the net because i had to prove a point in my work area ;) ... Then i stumbled upon this great blog post which i thought i should share with all of you which clearly explains when and how to use these String concatenation methodologies. And thankfully i was right in my assumptions :D.... The blog post can be found at http://www.znetdevelopment.com/blogs/2009/04/06/java-string-concatenation/