Project retrospection, my non-called role as acting Agile Coach

Last week I was discussing on the topic - What it takes to guide team of beginners or being agile coach in general, with Mat Hinze. That reminded me my role in previous project.

while people like Jeffrey Palermo are natural coach, personally I find it little difficult to work with beginner level people.

Looking back, here is quick highlight

• In first week, gave little presentation on what agile is and high level idea of how scrum works.
• Introduced unit test and integration test for the project. Started working in TDD way
• Change existing build process (Build = Compile) to include compile plus test execution (Which was later again changed to accommodate things like custom commonasseblyinfo, publishing coverage report and executable specification).
• Re-organized project structure to facilitate better support for loose coupling.
• Introduced boundary testing (or Scratch testing) to better integrate with external systems (and these systems where also under active development, using water-fall methodology, giving us hard time every time they give us new version).
• Introduced Dependency Injection technique to the team.
• Introduced pair programming (this was the hardest part, for me).
• Introduced using StructureMap for IoC.
• Introduced mocking technique to the team. Gave demo-cum-presentation on Rhino Mocks.
• Introduced MVP to work effectively in  ASP.NET WebForm environment. (Second hardest part on this project, for me)
• Re-factored existing code to eliminate gigantic code behind files.
• Introduced CruiseControl.net for build monitoring as well as deploying to staging environment.

Enough!!!!!!!!!!!!!!!!!!!!

What did I got out of this

• Team realized power of TDD and could see the real value behind it as oppose to doing just test first programming.
• Pairing helped team, breaking the knowledge silo and promoted collective team ownership.
• We had better success rate with sprints as we proceed further.

What was still left out:

• Project owner team, never truly realized power of Agile/Scrum
• I always had hard time convincing them for shorter sprint as oppose to 1 Month sprint.
• Sprint velocity was never established properly.
• Effectiveness of Sprint Retrospective was very low. (it turned out to be mostly time wasting activity)
• Planning meeting were always mess. Product owner were never ready with new set of requirement which they want in next sprint.
• Story related pre-requisite work was always done during planning meeting by making calls to 5 different people and then deciding on the fly, what needs to be done for the story in hand.
• All product owner never bothered to come for planning meeting.
• During sprint, one representative from product owner team was choose to answer team's question and was rarely available.
• Cubical structure made it very difficult to communicate with team effectively and has resulted in duplication of effort.
• Testing team mind-set was fully water-fall oriented. They never bothered automatic tests and continued manual testing focusing on trivial issues which were never called out in story.
• And the list can go even further, but I think I covered top pain points.

With this kind of project, I am not sure whether I succeeded in doing my best for the team. One thing however is sure enough that while I could make positive changes and affect the overall direction for technical team, I had almost no control/influence on people who were higher in the hierarchy. (By the way, I was originally hired to help them with reliable messaging which never happen in the project).

That spawns nature question, what should I have done differently to help this project better. And more importantly how would you handle this kind of situation where you don't have direct or indirect influence on people who are driving the project. ( And I am looking for answer other than; "Hey, why don't you just update your resume and start surfing dice or monster.com)

Working with high performing team

Not secret anymore, recently I have made one of the most significant move in my career my opting to work with the team HeadspringSystem, the premier agile consulting company based in Austin. It's been my pleasure to work with all BigB's like Jeffrey Palermo, Kevin Hurwitz, Mat Hinze and Jimmy Bogard.

Ever since I stated with new project with this team, I have been learning a lot every day. Be it NHibernate, NAnt, using open source project, spawning new open source project, NBehave, Community Contributed Framework, IoC or applying BDD at work; this team makes every thing so smooth and so juice that you can't live without that it.

Team operate , keeping in mind the sole intention of getting work done and giving product owner what they really like to see in the system (as oppose to doing just what they said initially).  User story flows naturally from left side of the board to Done Done Done column.

If you are wondering how this team attacks individual story, go to my buddy's blog here.

lastly, I here by taking over un-official title of least qualified team member from Matt Hinze. 

Burndown chart vs Burndown mentality

It's no surprise that scrum projects are using Burndown chart for tracking sprint progress and overall product release too.

Burndown chart, as name suggest, keeps burning task/stories as and shows what is still left out.
Every day after, stamp up meeting, is good time spot when we re-draw this chart to reflect previous day's work.

Here is the trap which I have seen many team fall in very easily. While we are using daily stand up to come up with burn DOWN chart, what we are really talking about is how much amount of task have been done (i.e. 4 hours or 1 story point etc). Now truly speaking that information is not really helpful to us. In Agile there is no look back. Whatever happened, does happened. No one in the world can go back and change them. What is important is what to do next. What I mean to say, is we need to start talking in terms of what is left in order to finish this story.

Now, does that sounds like weird argument? One might argue that, isn't that the same information. After all we know total size of the story and by telling what has been done, we can easily figure out what is left. (That's simple math I learned, way back in primary school).

Here is my answer,
My experience with past and present scrum project has taught me the above simple math of deducting completed point from original size is failing too often. While working on story we might encounter more or less complexity than originally anticipated. Which means, for then encountered simple story what is left is too less or for then encountered complex story what is left is much more. And somehow human minds are evolved in such a way that they can give more accurate answer for what is left vs how much is done.

Personally, our charts have improved a lot (in terms of reflating actual picture) when we started forcing team thinking in terms of "what is left" pattern over "what is done".

I call this pattern "BURN DOWN MENTALITY" to update burndown chart.

Thought? comments? arguments? I would love to hear.

Develop smartly :)

Xp Team sizing... Even or Odd

Yesterday, we had our sprint retrospective which brought one interesting issue.

We are team of 5 dev, 2 tester and 1 project co-ordinator.

One of the issue we have been facing since very beginning is lack of pair programming which resulted in knowledge silos getting build in the team. With extra effort and quoting past examples I succeeded in showing value in pair programming and we started doing it gradually more and more.

However last sprint's result was surprising to me. We had total 12 user stories in sprint and out of that I did 4 stories alone and then contributed for 3 more stories.

Now with the team of 5 developer, that sounds little ODD to me. So I tried to investigate this in the retrospective session. To my surprise, I heard other developers talking about working in pairs (2 pairs out of 4 developer) and their story comes out to be extra complex than what was originally thought of. So I was the ODD man out from the pair programming this time, for whole sprint.

This gives me interesting question. Should XP team always be Even size to facilitate pair programming? May be YES. (While voting for yes, I am well aware of the fact that even size might give us tie in planning session while estimating story point. My answer to this is use Feast-To-Five technique)

Anybody would like to comment? I love hearing from like minded peoples!!!!!

Develop smartly :)

How to get default value of given type

Found this interesting construct for .net based development.

While we all know default value of each type, at some point we might have generic implementation. So what if we need to make use of default value of give type?

Following method demonstrates, usage of default keyword (code sample in C#)

public T SomeMethod(this T abc)
{
if (whatever)
{
return some valid value;
}
return default(T);
}

This was new to me and in past I had situation where I wanted to return default value for variable type. Now I know exactly, how this can be done!!!!!!

Develop smartly:)

Agile Planning - Planning on wall

Till last week we were facing serious issue with respect to our sprint planning. Team is new to Agile and except me, everybody else is working on agile project for the first time.

Time was killer factor for our planning session. Almost every single time, we are running out of time and it ends up being 1.5 day planning session for 2 week sprint. (Again Business is also responsible for this mess as those user stories were half cooked meal and there wasn't any acceptance criteria)

Last week whole picture changed when we were successful in convincing business, that its important to have user story ready well before planning session. We used their own weapon against them and warned them without well defined user stories, the software is at risk and we will never be able to release it on time :)

That worked magically!

Business spent 2 days, organizing their thought, collected input from other concerned people and finally provided us well defined user stories which has clearly written acceptance criteria.

Wow... we entered greenland for the first time on the project.

Next was our turn and this time business wanted us to estimate them such that they call get idea on when can they release the product.

Looking at our history of planning this would have taken us, probably 4-5 days, if we would have continued to follow our old practice.

But we didn't had that much time. So it was necessity that became mother of new discovery, again.

Earlier when we used to estimate each story, we all where breaking it into task(This was sprint planning, against tasks and not release planning against user stories). And then discuss scope and complexity and come up with magic figure against each task. The whole operation was single threaded as everybody was on same task card and again getting conses for magic figure was taking time too.

So this time, we thought of using multi-threading for planning. And hence one of the wall of our Ping pong house, became playground for this planning. Every body in the team had 4x6 sticky note and a pen in their hand, No body seats in the room and then we have one person read story. (This guy was really proxy for business for us) Then starts Q&A session till we get all answers. Meanwhile everybody in the team uses their sticky and start writting all possible task that they can think of and stick on the wall. Sooner (less than 2 min) we have 10-12 task hanging on wall. They we just look at the cards and eliminate dubplicates. Task keeps on comming till everybody in the team, can't think of anything new.

Then starts next step, re-arrange task into logical order, either vertical or horrizontal.

Next and final step, was to give number to each of them. That starts with top most card, and any one call out number, others either agrees or give different number and then we uses Fist-to-Five to get agreement. Game is everybody vote for the number for given task, by raising either 1-5 figures. Number of figures means, different things as follow
1: Go to hell, I can't get this at all
2: I seriously doubt
3: Well may be good, I am Ok with that
4: Sounds good to me
5: totally agree

3 onwards is fine and you can accept that number for the card. However if even single 1s or 2s means call for further discussion and then second round with new figure based on that discussion.

Well, that's all. The whole thing worked dam good. Room was filled with lot of energy as against two or three sleeping members in the chair. Everybody contributed and we had our planning doen in one and half day without any overtime. We even had two 15 min break and one hour lunch break in between.

Above all, it was team's estimate. We created it together and we owned it. This has bought automatic buy-in from all members. Whole team was happy and everybody in the team had high degree of confidence in the estimation.

The whole magic worked!!!!!!!!!!!!!!!!!!!

I called it 1+1 > 2

Any thoughts, comments, queries, arguments??? I will be glad to hear.

Also how do you go for sprint planning?

Decorator pattern in Action

This time we are going to solve logging problem.
Requirement is as simple as that:
Login story: System should log all informational as well as failure messages into text file.

That sounds way simple, right? Even without using any existing logging framework.

All it takes is just one static class.
public static class Log
{
public static void Write(string message)
{
//code to write in text file
}
}

And the usage looks like
Log.Write(“something weird happen here”);

So far so good.
The solution works so far and meets our requirement.

Next, lets consider following some OOPs. Here is what I got from Head First OOA & D.
• Make sure your software does what client want it to do
• Apply OOP to make it maintainable.
• Re-factor to improve any duplication.

We have already satisfied first bullet line. So let’s proceed to second one.

One of the OOP says “Depend upon abstraction”. But in our solution, we are tightly binding client with static class. So let’s instead use interface and push all the concrete code behind it.

Our new implementation looks like this:
public interface ILogger
{
void Write(string message);
}

public class TextFileLogger : ILogger
{
private readonly ITextFileWritter _textFileWritter;

public TextFileLogger(ITextFileWritter textFileWritter)
{
_textFileWritter = textFileWritter;
}

public void Write(string message)
{
_textFileWritter.Write(message);
}
}

If we look at closely here, rather than writing code for IO into logger class, I have pushed them into their own class. Why????? Remember Single Responsibility Principle? Class should have only one reason to change, right? So our logger should be responsible for logging not for writing to text file. This also gives me good opportunity to unit test my logger. To achieve this goal, I have used one of my favorite Inversion of Control techniques called Dependency Injection [This might sounds like weird but I am favoring this approach because it gives me, unit testing benefits plus we have textFilewritter, which can be used anywhere else too].

Now, at this stage, our solution looks great. It perfectly meets client need as well as follows OOP from the maintainability point of view.

It’s been well said for software: The only constant in software is Change. So what if we have requirement coming up later: need to feed all these log messages to xyz MQ, so that somebody can take corrective action on them.

With our new code it should be that difficult as all we have to do is CHANGE TextFileLogger class. Add one line there, to make call to some class which will write into MQ.

Remember though, key here is our ability to reach at this file and CHANGE code in it. We may not be lucky to get access to source file every single time (This is the case, almost every single time when code that we wrote, is shipped as part of some framework). And again its always risky to change somebody else’s code. Now you have to test not only your new functionality but existing one too and make sure you haven’t broke any thing (Isn’t that very common, breaking existing code while making change. People working on maintenance project, knows this better than me)

Certainly, our solution is failing at this last litmus. We are in trouble again. Need Help!!!
I heard, one of our old friends, whom we never bother to call so far, can help here. So let’s knock her door. By the way, her name Decorator. Here we are at the door

Me: (Knock knock)
Someone from inside: Who is this?
Me: Hey I was looking for Decorator. Is this a right place where I can find her? I seriously need her help.
Door Opens.
Decorator: I am decorator. I am glad that you came here to help. Many programmers ignore me, either because they don’t know me or my power.
Me: What power you are talking about?
Decorator: Ability to add behavior without touching existing code.
Me: Sounds interesting. I am looking for something like that only. Could you elaborate on this.
Decorator: why not, here is what GoF says about me:
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Me: As always, that was big bumper for me ?
Decorator: Don’t worry. Let me simplify it for you. Remember me, when you have requirement to add extra behavior on top of existing one, without changing original code.
Me: I am with you. Go ahead
Decorator: So when it comes to add behavior, all you have to do is implement existing interface, in your case, ILogger, and keep reference to original one in your new class. So the new class looks like this
public class DecoratedMSMQLogger : ILogger
{
private readonly ILogger _logger;
private readonly IMSMQWritter _msmqWritter;

public DecoratedMSMQLogger(IMSMQWritter textFileWritter, ILogger logger)
{
_msmqWritter = textFileWritter;
_logger = logger;
}

public void Write(string message)
{
_msmqWritter.Write(message);

if (_logger != null)
_logger.Write(message);
}
}
Me: Ok, and now all I am doing is passing each calls to that logger, after I am done with mine
Decorator: Exactly. And by doing this, what you just followed is called, OCP.
Me: you solved my problem. Thank you so much and I promise to visit you again and again
Decorator: my pleasure, bye bye
Me: bye

PS: sample code already uploaded in my google repository.

Code sample for design pattern available

I have created new google code project for hosting all the code sample which I use through out the series of design pattern.
you can get it from here

you need svn client, for downloading this code sample.

Update on screencast: As I promised earlier, John and I are going to record screencast on each of the pattern, as we post them but so far other personal/work stuff has kept us busy so couldn't record any. Stay tuned at http://feeds.feedburner.com/mahendramavani for these screencast.

Very soon, I will be posting next one in the series

How to get latest changeset number from TFS within NAnt

I had hard time getting this up and running so thought of sharing here. Might be useful to someone.

This guy has excellent post on this topic, here

Its very simple and self explanatory, so I don't think I have to give any thing more. Just ignore other target and focus only on Version target

The real gut behind this comes from the C# code, embedded within NAnt task

Here is the unchanged copy of code snippet, in case you don't want to navigate way.

public static void ScriptMain(Project project)
{
project.Log(Level.Info, "Connect to " + project.Properties["tfs.server"]);
TeamFoundationServer tfs = new TeamFoundationServer(project.Properties["tfs.server"]);

// Get a reference to Version Control.
Type type = typeof(VersionControlServer);
VersionControlServer versionControl = (VersionControlServer)tfs.GetService(type);

project.Log(Level.Info, "get changesetId for " + project.Properties["tfs.fullpath"]);
IEnumerable changeSets = versionControl.QueryHistory(project.Properties["tfs.fullpath"], VersionSpec.Latest, 0, RecursionType.Full, null, null, null, 1, true, false);
int latestChangesetId = 0;

// there is only one
foreach(Changeset c in changeSets)
{
latestChangesetId = c.ChangesetId;
}

project.Log(Level.Info, "ChangesetId is " + latestChangesetId.ToString());
project.Properties["project.version.revision"] = latestChangesetId.ToString();
}

Strategy Pattern in Action

Let’s start with describing problem in hand. To be more towards BDD side, let’s define current context.

Here is the requirement cheat that we received from our client.

• An Eagle is a Bird.
• A Parrot is a Bird.
• A Crow is a Bird.
• A Sparrow is a Bird.
• All Bird can fly.
• Eagle and Crow fly the same way i.e. they print “FAST FLY” when the method is invoked.
• Parrot and Sparrow fly the same way i.e. they print “SLOW FLY” when the method is invoked.
• All birds eat.
• Eagle and Parrot Eat the same way i.e. they print “EAT GRASS” when the method is invoked.
• Crow and sparrow eat the same way i.e. they print “EAT FRUITS” when the method is invoked.

Our goal is to implement this, with in most maintainable fashion or call it best possible solution, which we can think of.

Sounds simple, isn’t it?

All we need is one interface, call it IBird, with fly and eat method. And then Eagle, Parrot, Crow and Sparrow will implement this interface. Base on our current thinking, our class diagram looks something like this:

public interface IBird

{

string Fly();

string Eat();

}

public class Eagle : IBird

{

public string Fly()

{

return "FAST FLY";

}

public string Eat()

{

return "EAT GRASS";

}

}

public class Parrot : IBird

{

public string Fly()

{

return "SLOW FLY";

}

public string Eat()

{

return "EAT GRASS";

}

}

public class Crow : IBird

{

public string Fly()

{

return "FAST FLY";

}

public string Eat()

{

return "EAT FRUITS";

}

}

public class Sparrow : IBird

{

public string Fly()

{

return "SLOW FLY";

}

public string Eat()

{

return "EAT FRUITS";

}

}

Wait a minute!! Are we sure this is best possible thing we can do here? Is this most maintainable/flexible solution that we can possibly have??

Let’s think over this!!!

Aren’t we repeating our self when we implement Fast Fly method in Eagle as well as Crow? Same thing goes for slow fly, eat grass and eat fruit method too. Clearly, we have more than one instance of our algorithms. So it fails on maintainability test (because now we have to remember that every time we change something or fixes some issue, we have to do it at two places)

Let’s run flexibility test now. Our client has come up with following new requirement

A Plane is not a bird.

Plane fly the same way as Eagle and Crow i.e. it print “FAST FLY” when the method is invoked.

Hmmm….. Since we have same behavior as in bird, how about implementing IBird and thereby get the behavior.

public class Plane : IBird

{

public string Fly()

{

return "FLY FAST";

}

public string Eat()

{

throw new System.InvalidOperationException();

}

}

STOP!!!! Does this make sense? C’mon… after all, plane is not a bird. And what does it eat? May be fuel, but our client didn’t specified any requirement related to that. One option could be to leave it as not implemented though.

Grrrrrrrrr!!! You are now violating ISP. Sounds like we are failing on this test too... Shame on us, couldn’t clear even one test.

We need help. F1 please!

Somebody is knocking our door. Let me go and open the door.

Me: Hey, who is there?

Voice from outside: Hey it’s me, Strategy pattern. I heard you screaming for help. I think I can help you. May I come in?

Me: hmmm… sure, why not? So why do you think you can help me with solving my problem?

Strategy Pattern: Well, you see, you are trying to put everything in inheritance base model and that is why you are falling in trap. Rather you can use compositional approach.

Me: ha ha ha… that’s too much jargon, just like Microsoft help. Now can you come to the point and tell me how to solve my problem, instead?

Strategy Pattern: Sure, lets re-consider our approach to this problem here. From the description, it is clear that we are talking about two different set of behavior, Flying and Eating, right?

Me: Ya, I can see that as well.

Strategy Pattern: ok, so lets define two interface called ICanFly and ICanEat, to represent them.

Me: sounds good to me.

Strategy Pattern: Now since we have Fast flyer and Slow flyer, we can implement them in class called FastFlyer and SlowFlyer respectively.

Me: Go on

Strategy Pattern: And then, we have FruitEater and GrassEater , which implement ICanEat. That makes our class diagram look like this:

public interface ICanFly

{

string Fly();

}

public interface ICanEat

{

string Eat();

}

public class FastFlyer : ICanFly

{

public string Fly()

{

return "FAST FLY";

}

}

public class SlowFlyer : ICanFly

{

public string Fly()

{

return "SLOW FLY";

}

}

public class GrassEater : ICanEat

{

public string Eat()

{

return "EAT GRASS";

}

}

public class FruitEater : ICanEat

{

public string Eat()

{

return "EAT FRUITS";

}

}

Me: I am with you. Carry on

Strategy Pattern: Finally, Eagle is fast flyer and eats grass so why not let it implement ICanFly and ICanEat interfaces. In our implementation of Fly, we will delegate this task to FastFlyer and for Eat we will delegate to GrassEater.

Me: Now you are going to tell, we can do same thing for Parrot, Crow and Sparrow too, right?

Strategy Pattern: you are smart! So that gives us new picture like this:

public class Eagle : ICanFly, ICanEat

{

public string Fly()

{

return new FastFlyer().Fly();

}

public string Eat()

{

return new GrassEater().Eat();

}

}

public class Parrot : ICanFly, ICanEat

{

public string Fly()

{

return new SlowFlyer().Fly();

}

public string Eat()

{

return new GrassEater().Eat();

}

}

public class Crow : ICanFly, ICanEat

{

public string Fly()

{

return new FastFlyer().Fly();

}

public string Eat()

{

return new FruitEater().Eat();

}

}

public class Sparrow : ICanFly, ICanEat

{

public string Fly()

{

return new SlowFlyer().Fly();

}

public string Eat()

{

return new FruitEater().Eat();

}

}

Me: Wow, you see that solves my problem, because I am no more repeating my algorithm here. It’s been implemented at just one place

Strategy Pattern: Of course. Do you see any other benefit too?

Me: Hmmm. Let me think………………….

Me: Yes, you see, now I can have plane which implements only ICanFly interface and I am going to delegate actual implementation to FastFlyer again.

Strategy Pattern: right, that gives you

public class Plane : ICanFly

{

public string Fly()

{

return new FastFlyer().Fly();

}

}

Me: And it also passes my second test of flexibility because I could change my design to accommodate new enhancement, very easily.

Strategy Pattern: There you go.

Me: Thank you so much strategy pattern. I am glad that you came here and taught me such an important lesson.

Strategy Pattern: I am glad too, that I could be of some use.

Me: Last thing, I would like to ask though, how do I recognize you in future? Do you have any formal identity?

Strategy Pattern: Oh ya, I am defined as

“Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.”

Me: sounds great, and once again thanks for this valuable lesson. I guess we will meet again very soon J

Strategy Pattern: bye bye, and Develop smartly J

-------------------------------------------------X-------------------------------------------------

That was end of my first session on the ongoing series of blog about design pattern. I am planning to upload all my code sample on google code repository. So watch out at http://feeds.feedburner.com/MahendraMavani for more update.

Also, along with my colleague, John Teague, I am going to record screen cast on strategy pattern. This screen cast will briefly cover what I have discussed here and then we will jump to real life usage scenario of strategy pattern in action.

Disclaimer: I am not claiming to be design pattern expert. This is just 2 cent from my side to feel the ocean. I welcome comments, suggest, concern, query and healthy argument on this post. Please feel free to drop your opinion in the comment section.

Design Pattern Series - Table of content

As promised in my earlier post about this series kick off here is the table of content.

Entry in this table will directly point to post once it's online, So you can bookmark this blog as index to whole series. Entries are not in any particular order and we might post 3 and 4th before 1 or 2nd. Idea is to make all of them available at the end of this session.

• Strategy - screencast
  
• Observer - screencast
• Decorator - screencast
• Singleton - screencast
• Command - screencast
• Factory, Factory Method - screencast
• Abstract Factory - screencast
• Difference between Factory method and Abstract Factory
• Template - screencast
• Difference between Factory and Template
• Adapter - screencast
• Facade - screencast
• Difference between Adapter and Facade
• Iterator - screencast
• Composite - screencast
• Compound - screencast
• State - screencast
• Proxy - screencast
• Difference between Decorator and Proxy
• Visitor - screencast
• Builder - screencast

Develop smartly :)

Why do we need to know design pattern?

Probably, we all know definition of design pattern from wiki that its general reusable solution to a commonly occurring problem. And of course we have thousands of web pages over internet, telling about these patterns every now and then. Aha! Don’t forget those dotfactory for GoF.

So the natural question that comes in my mind is, WHY one more? Here is the answer I got from within

While many people know these patterns by definition and by class diagram, what is missing really is what they actually mean when it comes to applying them in practical scenario. Most importantly knowing when to apply and when not to (Nothing is as bad as applying design pattern at wrong place). Besides, what matter more in practical cases are design principles and not just blind application of any pattern (just because you know that pattern). After all ultimate goal behind any design pattern is to encapsulate what is changing.

With that in mind, I am planning to start with series of blog on design pattern, along with my friend John Teague. Our goal is to

• Uncover design principle buried behind each design pattern
• Dig bit more into practical application of pattern over just definition and class diagram
• Going beyond “General reusable solution”
• Finally, disclosing why everything you hear about these patterns from your friend is almost wrong.
• Avoiding those silly coupling mistake which gifts you sleepless night just before release.

Here are few important bookmarks, which you might be interested in keeping eye on:

http://www.lostechies.com/blogs/johnteague/

http://mahendramavani.blogspot.com/

Alternatively, you can subscribe to our RSS feed at

http://www.lostechies.com/blogs/johnteague/rss.aspx

http://feeds.feedburner.com/mahendramavani

I will soon post about overall outline of this series of blog. In short, as of now, idea is to cross post on both of above space and each design pattern will followed a screen cast which will demonstrate example discussed in the blog. These screen case will be a very good example of pair programming too.

Watch this space… much more interesting to come

Develop smartly :)

changed to feedburner for RSS

Here is link to my rss feed

http://feeds.feedburner.com/mahendramavani

I am planning to post series on design pattern in action. Keep tag on this url to learn more.

Code smartly :)

is it a good idea to include source safe binding information in solution and project file?

Microsoft is, as usual, kind enough to give yet another headache to the development team when they gave TFS. I bet its just copy paste from VSS code. (After all both sucks equally)

What I don't like about both of them is the fact that they uses .net solution file and project file to keep track of these binding information.
Now even if I agree that microsoft was kind enough to give those .sln and .csproj file, that doesn't give them luxury of using those file for whatever they think would be OK.
Now when I am working in integrated VS environment, my .sln and .csproj file has many reason to change and I end up, checking then in every single time. And of course, those .vsssc and what not are all your friends. Every single time when you what to check in, this extra noise is always present.

Dam it!!!! Microsoft sucks....

Why can't I have something like subversion. You better keep track of your binding stuffs separately. Give me subversion and I am happy on any day. But never VSS or TFS

I have been fighting on my current project to see if we can change source control. But the real problem is client has standard across all projects to use TFS. (Some people are blind follower of MS)

So best of luck to me again!!!!!!!!
I am hopping to make difference here.

why would you use scrum?

So far I have seen many reason for why an organization should start doing scrum over waterfall.
They all ultimately nail down to some of these:

• Frustration
• Not able to meet deadline
• Increased stress towards the end of the project.
• Software with nice to have features but has almost nil business value.
• Historical failure in the project

3 days back I have started with my new assignment and was very excited for working for one of the big B in the industry. Again from what I learned from job description and then during the interview process,was promising too.

Now since I am insider here, I know some of the ground reality. Here is the few comments that I heard on very first day, as reason for choosing scrum methodology for my current project.

• This project was in planning phase since last 18 month and we never had something concrete which can be shown to upper management.
• No one know about project requirements and after searching little bit, we found scrum as the only methodology which allows us to work without requirement.
• We don't have any process or discipline and scrum is the only possible ad hoc way to do this

After hearing all this, it might sounds frustrating but the silver light here is that: team is really interested in trying this new methodology and they do believe in making things done. People are open for trying new things and learning.

So here is what I am thinking of doing

• Introduce TDD and BDD(yes they aren't doing it either)
  
• Scrum training for team and upper management (session as well as on the job demonstration)
• Pairing with each member for getting them up to the speed (Playing red-green-refactor game)
• Re-structuring project solution and refactoring overall architecture.
• Introducing SRP, DI, IoC to the team.
• Start using structuremap, NAnt, MSTest, Resharper, RhinoMock

Well, best of luck Mahendra! Hope you can make difference.

finally, Jeffrey is the great guy. I owe all these learning to him, which I am going to implement here. Hey Jeff, its party time for you. Your teaching is paying off here :)