When adding new team memebers... off set the ramp up time by

1) having pre built machines ready and and easy method of getting the lastest tools, code base etc.
I'm fortunate enough to be at a client that has a machine ready built and loaded when the dev arrives, all they have to do is grab the code.

2) have tasks broken down so that dependencies are as minimal as possible. In other words, to over come the mythical man month issue (as recently mentioned on slashdot) make sure the tasks you hand out have few dependencies on each other. That way the new dev is able to be productive fairly quickly.

Here's our historical lead time... the bump in Jan is due to added work, by 2/18 we had added 4 new people over the last two weeks. And amazing the time starts coming down:

Here's our averag work time:

again time ramps up as we are adding more tasks, but then starts inching back down through out Feb and March.

It's not that we beat the Mythical Man Month, and in fact I still believe the book and idea are highly relevant. But if you can break the tasks down and reduce the dependencies between the task then you can mitigate the effect.

The tool used in this case is from AgileZen.com and some of the wild swings are due to inexperience with the system initially... but our average times as measured by the tool are matching real life. Also the tool appearst to measure in 24 hour days and 7 day weeks. so it isn't as bad as it looks. :-)

More for helping me to remember...

One good reason, at least during development, for putting your web application/service in its own app pool in IIS? Recycle...

There are times when you'll want to recycle, normally done by restarting IIS, to make sure it updates and recompiles against your current dlls.

But in a shared environment it's not very polite to restart IIS and mix up your fellow devs.

So throw the app in its own pool, problem solved, as it were. You can restart just that pool and not have to restart the whole IIS service.

Again pretty minor, but useful to remember.

I find it interesting how people think... what makes sense to them, et.c so...

There's how I think...

SomeObject.ListOfPeople.FindAll(

type => type.GetType().Equals(typeOf(Individual))).ForEach

(person => { DoSomethingWithPerson(arg1, arg2);});

Pretty straight forward lambd Final all of x type in this collection and then do something to each one found. But coworker suggested this instead:

(from person in SomeObject.ListOfPeople

where person is  Individual

select person as Individual).ToList().ForEach(person => {DoSomethingWith Person(arg1, arg2);});

So both do the same thing... and there's no performance difference, just depending on the coder one way is more readable than the other. I happen to like lambdas but I'm on team where the devs find the more SQLish style to be better (sorry blanking on the formal LINQ name).

One thing that sinks my lambda though. ListOfPeople has to be an ObservableCollection<T> and that doesn not support the FindAll method, unlike the generic List<T>.  Digging a bit ObservableColleciton inherits from Collection<T> (makes sense) which is more limited than List<T> in methods provided. c'est la vie.

Mainly going to use this as notes and such of what were discovering by overlaying WCF on an existing application.

So the set up...
In existence is...
1) a working web application
2) a server back end to support the web app (that we get to use for our needs)
3) a relatively complex hierarchy of classes (e.g. a inherits from b inherits from c, some interfaces are also referenced by c, as well as complex types.)

Our app will be a client/server application where the client will be in various offices located across a large geographic area. They communicate with the central office via a decent size WAN. Of course to do this communication we'll be using WCF.

O.k. issue number one...
we have a series of forms that have back end business objects with 3 layers of inheritance.

So first obvious "solution"...

Make a facade and have the service do the translation.

In other words look at the UI end and create a simplified object model based on that. One that will work easily as a data contract in WCF.

Then on the service end translate the incoming data into the needed business objects.

Upside - good separation,  don't have to touch business end
Downside - could be lot of upfront work if you're app will be doing a lot of back and forth between on screen and the client.

O.k. yes I started with the uber easy one... next what tools you can use if you have to serialize the actual business objects.

oh and code examples... as the above is just off the top of my head.

Having binding issues? No not that sort...

So more for my own poor memory, we have a project where references will throw errors like "The located assembly's manifest definition does not match the assembly reference." Not terribly useful.

But MS has a tool that can aid in diagnosing these issues, Fusion Log.

1. Open up a VS (2k8 or 2k10) command prompt.
2. Type fuslogvw.exe
3. You should now see:
   
4. Next run your program, this can even do this from a test project. To isolate the issue just run the relevant test method via "Run Tests in Current Context"
5. Click on the Refresh button and the list of bindings should show up:
   
6. Highlight an entry and click on View Log. It will give more details about what was loaded and hopefully a better error message for diagnosing why the module isn't loading.

That's it for now...