I’m currently working on a project that has a large amount of files and projects, as you can imagine managing all those files and projects can get a little unwieldy.  We as a team realised this, and decided to take some time out in order to reduce the amount of projects.

Now one of the tasks I was asked to do was to merge a number of the core projects into one project, this involved moving around 50+ files into the project that we were merging into.  So, with my task assigned to me I gallantly completed the task by simply moving the required files into the project, and hey presto job done.  Or was it?

As you may know that good development practice in .NET requires the developer to ensure that the namespace follows the directory structure from project root down to the file. Now moving the files was ok, but the job was half done, the namespaces did not match the dir structure of the files new location.  Ok I thought, I’ll just update the namespaces, but there was a lot of files 50+ files.  Ok I could just use find and replace, but that means I could screw it up because it requires my intervention.

What I needed was a addin that detects the incorrectly specified namespaces in the files, then when you have confirmed that you wish the files to be corrected, it’ll not only update the namespaces, and as a bonus it’ll update all the references, usings and clean up the code as well.  Funny enough there is such an addin, and it’s called (drum role) Resharper.

What you can do is select the offending files in the solution, either by right clicking on the selected files, or by right clicking on a project or solution folder in the solution, and then by selecting the menu item Refactor->Adjust Namespaces, you’ll then be presented with a wizard detailing the files that have been detected, clicking next will start the process.  After a while all the files and references will be updated, leaving you to save all the files afterwards (by default the wizards opens the files it has changed).

Now, this is just the tip of the iceberg regarding Resharper, it is a very powerful addin, not cheap, but well worth it in helping to speed up development, I recommend that you download the trial and give it a go, it supports VS 2008, VS 2010 and also VS 2003 as well.

Just recently I’ve been creating projects in Visual Studio 2010 for SharePoint 2010.  My projects where getting very deep in the filesystem, where the upshot of this is that the file path was getting very long.  To my dismay if you try and deploy a SharePoint solution that contains very long paths (>260 char) it fails.  Now in this day of age, that is not good. 

Now i’ve been reading around and found that the limit is imposed by the WIN32 API, however, I know that NTFS supports file path lengths of 32K. Now that is one hell of a difference.  When we hit this 260 char limit our first reaction is to shorten the file path somehow, but it does not seem right.  Further reading finally led me to a way to get windows to allow file paths upto 32K.

To get windows to allow for path up to 32K you simply prepend the file path with \\?\ and away you go.

Ie copy \\?\c:\<Very long path> \\?\d:\<Very long path>

Now the thing is you can use it in your windows apps to support 32K path lengths and hey presto, a windows app that supports 32K.

Update :-

I found this snippet

The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

This was extracted from the MSDN.

So use it with caution.

As you’ll no doubt be aware that i’ve joined forces with Andrew Woodward at 21Apps (www.21apps.com). I’ve worked with Andy for about two years, on and off on various projects, and found him to be passionate about Agile (SCRUM/XP) and since we share the same views and vision it seemed the logicial step to join forces and help others enjoy the benefits of Agile.

Sorry for the short, hopefully this blog will be updated on a regular basis. Ta Ta for now.

In our planning games we’re using the tried and tested approach of post it notes and white boards.  However, we found that when we were writing the tasks out the team members were writing the tasks in silence, which meant knowledge sharing was not really taking place and the team members were really estimating on a task they had little or no say in.  Which meant that sometimes, when we got into the iteration, one or more tasks didn’t seem to really fulfil the story and we were having to do extra work, at best, or, at worst, dump the story altogether.

So, a solution was needed.  What the team did was come up with a scribing system.  It’s quite simple, these are always the best ideas, a member of the team scribes (writes onto the whiteboard).

What happens is that a team member is chosen to scribe.  That person writes down verbatim what the TEAM thinks will be the appropriate task(s) to deliver the story. The scribe does not guess the tasks, they do not make suggests, they are merely dictated to by the team.  Once all the tasks are written then the team transfer the tasks onto post it notes and estimates.

We found that scribing forced the team to think about the tasks more, it also allowed the team to enter into a lively debate about the required task(s), thus spreading knowledge.  Another added bonus scribing has is that things that may have been missed, were not, because whole team is writing the task collectively.

Try it, it’s nice.  A word of warning though, we found that scribing on all stories we found that it’s causes the planning game to drag on a bit.  So we only scribed on stories that appeared to be complicated, but to be honest that’s just us, try it for yourself and see how it helps then adjust accordingly.

One further note, is that the teams that use web based story and task tools, ie Version One, XP Planner, etc, maybe already be doing this.  ie one person sits at the keyboard whilst the other team members tell the person what to type, so if your team are doing that then you are already benefiting from the scribing approach.

Happy scribing.

Where I’m currently working we were finding that our planning games were becoming a bit strained.  We found that when we came to estimating our stories we found that the estimates were a bit varied.

Now, we all know that if the estimations are very different in a planning game you stop to discuss why there are differences in the estimations.  Once the reasoning why the estimations has been discussed, the team can then re-estimate with new knowledge and hopefully things should be more or less the same, if not repeat.

That was OK after a while, but what I mean by varied people were giving funny estimations like 12.5, 4.7 so on and so forth, and no matter now draconian we tried to make the estimation process these silly little estimations kept on cropping up, which slowed the estimation process down and just generally frustrated people.

What we needed was a predefined set of numbers that we can all use, where we can quickly show what our estimation is.

After a bit of searching I found the planning poker cards from Mountain Goat Software.

How you use them is quite interesting, each developer has a pack.  In the pack consists of the following cards :-

• ? = I’m not playing
• 0
• 1/2
• 1
• 2
• 3
• 5
• 8
• 13
• 20
• 40
• 100
• ∞ = Greater than 100

When it comes to estimating the developers all hold up the cards at the same time, if they are mostly all the same the team goes with that estimation, however, if they are varied then the team quickly discuss the variances then re-estimate.

If the developer has no clue about the task the team is estimating they hold up the ? card, if however, they think this story is too huge they show the ∞ card, this is probably an indication that the story is one hell of an epic and really needs to be broken down.  The numbering scale also helps to stop people giving silly estimates of small increments.

When you read around how to use the planning poker game cards, you’ll see that they are used mainly estimating stories, but we also use them for estimating the tasks as well, with great effect.

This may seem a bit unprofessional, but our team have found that it helps to speed up the planning games greatly.  Firstly by introducing a strict numbering system, so we don’t get the x.something nonsense, and introducing an element of fun, and as we all know that time goes by much quicker when you are having fun.

I’ve been working with a team for a while now who use XP.   Writing user stories is OK and they are written very well, but writing developer stories posed a few problems.

The problem was this :-

We had a tendency, to actually write the story in such a way that presented the solution rather then the problem, and this seemed to cause problems and confusion.

Example of writing a bad developer story :-

As a developer I want to create a script that will run all DB scripts in succession so that I can easily refresh my development DB.

As you can see the solution is already presented in the story, not good.  This is mainly because it’s not giving the development team the wiggle room to come up with a solution.  The thing is the developer who wrote is giving his/her own take on the solution without consulting the rest of the team, thus not allowing for other team members, who might have a better solution, to present their contribution in the planning game.

So, what we need is to re-write the developer story in such a way that gives the team to reach a consensus on what is the best solution.

As a developer I want to address the issue of deploying the latest DB to my development DB with the minimum of fuss, so that I can start work sooner.

This is much better because it talks about the problem rather than the solution.  Now, you might be saying that “Isn’t it how you write stories anyway?” and you’ll be right from a customer’s story writing point of view, but I think as with my team of developers, we know a little bit more about the system, which influences our story writing towards a solution rather than describing the problem.

I’m sorry, where you expecting a drum roll?  No it’s just me James Fisk, I’m a developer of ten years plus specialising in ASP.NET, SharePoint,Spring.NET and Agile.

Hopefully this would be a regular place to dump my thoughts and so forth.

My company is called ‘Dititus’ it doesn’t mean anything I just thought it sounded good and it allowed me to get a .COM domain.  You wouldn’t believe how differcult it is to get one those nowadays.  Anyhoo the reason why I decided to call this blog ‘Spring loaded’ is because i’ve started to use Spring.NET a lot and it was also the first thing that popped into my head and I think that you’ll agree they are always the best type of titles.

I hope this blog will inform and stimulate, or at least, just humour. If I achieve any one of those I’ll be a happy man.

Thank you

James Fisk