Scaling ALT.Net Concepts
time to read 5 min | 972 words

I am having a lovely discussion with Casey (and others, of course) in the comments, I suggest that you would check it out, but I wanted to reply to this comment from him:

This started at ALT.Net and the Enterprise ... where you wondered why these things are believed not to scale up to (for example) 100 developers. I suggested the reason was that the great majority of those developers were 'body count', hence you had to let the overall team take the common approach (which I referred to as simple).
In that case, no these 'revolutionary' things won't scale, because you are hiring from a pool of developers that grew up with drag, drop, VB6, WebForms and Intellisence. So your options are: train 90 developers to use better techniques (while paying them) or use the things they are comfortable with and get some kind of result.
Managers will almost always pick the second. As a technical person, I asked you how you could convince them to take a better approach, without using any technical terminology.

"some kind of result" also include a steaming pile of fresh fertilizer, you realize. And explaining to management that they are going to set 90 developers loose, without any organization except the least common denominator is not a position that I ever want to be in. Nor do I intend to have seminars about OO or IoC, that is not productive unless you have good audience, and the way Casey portrayed those developers... they are not good audience.

Nevertheless, Casey is missing the third approach, on job training. What do I mean by that?

If I am going to have a project that have hundred(s) of developers, I am going to have to ensure some sort of a structure. I don't think that anyone can argue over that. Part of this is the solution structure, basic architecture, etc. When we do that, we lay down the basic principals of how we are going to work, and then pass it to the rest of the developers.

I don't really like this approach, it smacks too much of the architect in the ivory tower, and I would rather try something else, but let us go with the assumptions. So, we break down the types of tasks that we need to handle in the application (create a handler for remote action, build a web page, etc), and then setup a list of steps that needs to be taken in order to make it happen. We also supply several completed tasks of each type for reference (and copy/paste, sigh).

The design goals under those circumstances are to make it simple to build business functionality, and push all non business functionality to the framework. Under normal circumstances, the developers should not be aware of any of the "advance" stuff. They should be encouraged to show interest, and understand the entire stack, but they don't have to.

The end result is that you get them into the habit of writing good code, and it grows on them. Code reviews serve as a way to direct them toward maintainable code, especially if you are doing it live, so they can see how the code become simpler.

I am not talking gospel here, this is what I am facing at my current project right now. Using this method, we get significant improvement in the team efficiency, we get readable, maintainable code, and we get propagation of good habits. As an example, here is a piece of code that one of the my team mates has written, I run a SVN Blame on it, and he is the only one that touched it. I haven't reviewed it yet, obviously, otherwise I would have told him to put the missing public in its place, like it is supposed to be.

[Handles(CrmOperations.PostCreate)]
class OnCreateDeathProcess_CreateUpdateSupervisorsTask : DeathCommand
{
	public override void Execute()
	{
		if (IsDeathProcess == false)
		{
			return;
		}

		task updateSupervisors = new task();

		updateSupervisors.subject = Resources.UpdateSupervisorsOnDeathProcess;
		updateSupervisors.ownerid = GetEmployeeManager();
		updateSupervisors.scheduledend = ToExecuteImmediately;
		updateSupervisors.regardingobjectid = new Lookup(EntityName.wbs_employee, 
                                                PostState.wbs_employeeprocesstoemployee.Value);
		Create(updateSupervisors);

	}
}

Just thinking about it, this example uses WCF, IoC, ASMX Web Services, etc. But you would be hard pressed to find any of them exposed in this example, or in 99% of the rest of the business facing code base.

I just did a scan of the code base, most of the classes that we have are 1Kb - 3Kb in size (sorry, no line counts, I did it in explorer), and the biggest class that I have is 5Kb and has ~290 lines of code, it is also the base class for a lot of functionality, so it contains a lot of helper methods and similar functionality.

Not everything is golden, obvious. A brief scan of the code base found me this:

wbs_serviceorder serviceOrder = Crm.Retrieve<wbs_serviceorder>(serviceOrderGuid);
if (serviceOrder.wbs_serviceordermanningcount == null)
{
	serviceOrder.wbs_serviceordermanningcount = new CrmNumber();
	serviceOrder.wbs_serviceordermanningcount.Value = 1;
}
else
{
	serviceOrder.wbs_serviceordermanningcount.Value++;
}

This annoys me because it means that I didn't explain stuff properly, this could be written like this:

wbs_serviceorder serviceOrder = Crm.Retrieve<wbs_serviceorder>(serviceOrderGuid);
serviceOrder.wbs_serviceordermanningcount = (serviceOrder.wbs_serviceordermanningcount ?? 0);
serviceOrder.wbs_serviceordermanningcount.Value += 1;

But those are fairly minor issues, and easily fixed.

So, again, I have a team that doesn't know about anything about all those 'revolutionary' notions, but they are using it every day, we are gaining tremendous amount of value out of it and we produce maintainable code, one that we can work with in a year from now, which we know we will have to do.

So yes, I firmly believe that those ideas can most certainly scale.

Tweet Share Share 10 comments
Tags: